Re: gtk-fortran 19.04 released
On Fri, 2019-04-26 at 18:21 +0100, Emmanuele Bassi wrote: > It most definitely is not. The project is actively maintained, and it > recently got even a full description of the XML schema: That is interesting. Well 172 open issues https://gitlab.gnome.org/GNOME/gobject-introspection/issues but indeed there is some activity. I think 3 years ago when I started the gobject-introspection bindings it was nearly death. >gtkmm is an old binding, and it's very much set it its ways. Newly written bindings should not go down the same route. Yes, but his fortran ones is from 2011. So switching to gobject- introspection is much work. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk-fortran 19.04 released
On Fri, 2019-04-26 at 17:58 +0100, Emmanuele Bassi via gtk-list wrote: > Have you considered using the GObject introspection data that GTK > itself generates, instead of your custom parsing code? But a warning: GObject introspection is not that much fun, as it is in zombie state. Starting with the API docs was really hard, took me some hundreds hours before useful code generation started. Well, I started from scratch, but with some help of Mr Mansour. Maybe a start with a copy, maybe from python would have been easier. Note that Gtkmm does not use GObject introspection still. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk-fortran 19.04 released
On Fri, 2019-04-26 at 09:46 -0700, vmagnin wrote: > oncerning the "new discourse forum", I am not sure of what you mean. It is this: https://discourse.gnome.org/ Was recently advertised by Mr Bassi. The gtk mailing list will be closed soon, at least this one and gtk-app-devel. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk-fortran 19.04 released
On Fri, 2019-04-26 at 04:06 -0700, vmagnin wrote: > Launched in 2011, the gtk-fortran library offers interfaces to around > 1 > GTK functions Funny. I know how much work such bindings take, I created the Nim bindings twice, oldgtk3 lowlevel bindings, and high level gintro ones :-) Are you the main author, or do you have at least some understanding of GTK3? And is there a good reason that you have not posted this message to the new discourse forum? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Setting the scroll position of a GtkTextView in GtkScrolledWindow after render
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: The Future?
On Sun, 2019-03-10 at 09:38 +, Emmanuele Bassi via gtk-list wrote: > Nobody involved with the development of GTK even reads this list, > except me, I had that impression in the last 6 years, thanks for confirming. My conclusion was, that nearly no one was working on or with GTK any more. Because it is really hard to imagine that someone still interested in GTK not even read this list. (OK, for giants like Donald E. Knuth one would be not surprised, I once heard that he switched off email totally) I have asked google about GTK a few times in the last years, what I found was basically: Some blog post about you (I think it was that you have no much hope for Vala, I do agree), something about a woman from south America who was working for a few weeks on a game sponsored by GSOC, and some notes from someone like Carlsen, but I can not remember. So I have not yet investigated that Discourse mentioned recently on this list, maybe I should do? GTK has some justification still as it can be used from many programming languages easily. I guess you know my GTK3 Nim bindings https://github.com/StefanSalewski/gintro It is not perfect yet, and was some work to do. And I think that bindings for C++, Python and Rust are fine. Bindings for other languages like Ruby, Haskell, D-Lang, Crystal exists basically. And while most people would prefer Qt GUI creating bindings for other languages seems to be really hard, due to C++ classes, templates, MOC and all that. Qt may be fine when one is using C++, and someone told me that at least Python wrapper is not that bad, and I think I saw some basic Crystal bindings recently. But generally creating complete, bugfree high level Qt bindings is very very hard or at least very very much work. So I have not much hope for excellent Qt support for all the interesting new languages which appeared in the recent years. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re:
On Wed, 2019-02-20 at 11:49 -0600, Igor Korot wrote: > I know I am kind of switching the topic here, but... > > Why do we even talking about button number, when the doc explicitly > said > "right-click", which implies "right mouse button". Yes, I noticed that contradiction myself when answering your question. I would assume that "right mouse button" is what is generally used, but other buttons may work also or may work in future, maybe in GTK7? Should be not too hard to test. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re:
On Wed, 2019-02-20 at 11:07 -0600, Igor Korot via gtk-list wrote: > Hi, ALL, > This link https://developer.gnome.org/gtk3/stable/GtkToolbar.html#Gtk > Toolbar-popup-context-menu > states that the parameter "button" can be "-1". > > What is the scenario when this occurs, i.e. it should be the button > number that was clicked IIUC? > > Thank you for clarification. > Please use a more meaningful Subject next time. And you may consider reading the API docs you linked to more carefully: https://developer.gnome.org/gtk3/stable/GtkToolbar.html#GtkToolbar-popup-context-menu "Emitted when the user right-clicks the toolbar or uses the keybinding to display a popup menu." So it seems to be obviously that button = -1 is the case when a keybinding is used to display a popup menu. (Because for this case there is no button involved.) When you continue reading the API docs, it is even more clear: "The mouse button number is given by the button parameter. If the menu was popped up using the keybaord, button is -1." ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
GObject Introspection, how to suppress GTK4
I have a Nim gintro user who has both GTK4 and GTK3 installed on his box, and seems to have some trouble: https://github.com/StefanSalewski/gintro/issues/30 I can not test that, because for my Gentoo Linux box only GTK3 is official available. My gintro package should generate latest GTK3 bindings for Nim programming language, and ignore GTK4 for now, as I am not able to test GTK4, and without testing there is no chance for working GTK4 bindings. But it looks like he is getting GTK4 -- I assume he has a Linux box. From https://developer.gnome.org/gi/1.56/GIRepository.html#g-irepository-get-default I do not see how one can really select GTK version. For most people my generator program seems to work, because they have GTK3 installed. I am using g_irepository_get_default() and g_irepository_require() -- the later function gets NULL for version. May an undocumented pattern work for version? Like a guessed "<4.0" ? Or may a plain "3" give us latest available GTK3? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Simple question...
On Fri, 2018-06-29 at 22:38 -0400, Chris Moller wrote: > ...but I can't figure it out: How do I make a tiny little button, > like 10x10 pixels, gtk_widget_set_size_request (button, 10, 10); > doesn't work. gtk_widget_size_allocate (GtkWidget *widget, > GtkAllocation *allocation); doesn't work. ( can't make anything work > using CSS. Nothing seems to work. > Yes, it really should be possible to make tiny buttons -- and to some degree it is possible, gedit for example has multiple tabs, and each tab has a tiny close button. I have copied that gedit code once and got it working, was my Ruby code that time. But that gedit code has changed multiple times, so it may be necessary to copy most recent version. And of course it may not work for all widgets unfortunately. Of course, generally widgets should be NOT tiny, we all know that. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Size allocation warning message
On Mon, 2018-06-25 at 23:20 +0200, Rafal Luzynski wrote: > I assume this is your application or at least an application > for which you have the source code and you are going to fix it. That are some of our applications, and at least some of ours get such messages since at least one year, for example (evince:3250): Gtk-WARNING **: Allocating size to EvSidebar 0x55eab6d1b680 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? There has been multiple complaints about that on this list, but it seems to be not really easy to debug. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to shift surface?
On Mon, 2018-06-11 at 16:11 +0200, Stefan Salewski wrote: > Various C codes you may find in this thread, I think first Uli > Schlachter post has a link to the most advanced C version. Ah -- forgot to copy that link: https://lists.cairographics.org/archives/cairo/2016-October/027791.html ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to shift surface?
On Mon, 2018-06-11 at 08:29 +0100, Göran Hasse wrote: > Hello! > > I am trying to write a gtk + Cairo application that mimics the > animation in > wikipedias sine graph. > > https://en.wikipedia.org/wiki/File:Circle_cos_sin.gif > > There was posted an example some time ago -- in multiple versions. First one did only clear and redraw -- which gave high CPU load. An improved version of Uli Schlachter used shifting of display to reduce load. A Nim version of first simple redraw is available here: https://github.com/StefanSalewski/gintro Various C codes you may find in this thread, I think first Uli Schlachter post has a link to the most advanced C version. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Beginners guide
On Fri, 2018-04-27 at 14:54 +0100, Emmanuele Bassi wrote: > There are various wiki pages that you may be interested in; see the > "How Do I" section: https://wiki.gnome.org/HowDoI/ I wonder that you do not recommend the page https://developer.gnome.org/gtk3/stable/ch01s04.html#id-1.2.3.12.5 Is that one already outdated? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Beginners guide
On Tue, 2018-04-24 at 19:39 +0100, Jim Reilly wrote: > I have put together a guide to help beginners >All GTK+3.0 programs contain the same basic instructions, and Well, maybe you should also mention the preferred GTK3 app style as I did in the second example in https://github.com/StefanSalewski/gintro ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Reduce the size of a GtkScale indicator
On Fri, 2018-03-30 at 22:25 +0200, Stefan Salewski wrote:
> You may even name your widgets and then can set
> CSS properties of single widgets.
Like this:
import gintro/[gtk, glib, gobject, gio]
proc appActivate(app: Application) =
let window = newApplicationWindow(app)
let scale = newScaleWithRange(Orientation.horizontal, 0.0, 100.0, 10.0)
scale.setName("MyTinyOne")
echo scale.getName
let cssProvider = newCssProvider()
let data = "scale#MyTinyOne slider {min-width: 4px; min-height: 4px; margin:
0px}"
discard cssProvider.loadFromData(data)
let styleContext = scale.getStyleContext
assert styleContext != nil
addProvider(styleContext, cssProvider, STYLE_PROVIDER_PRIORITY_USER)
window.add(scale)
showAll(window)
proc main =
let app = newApplication("org.gtk.example")
connect(app, "activate", appActivate)
discard run(app)
main()
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reduce the size of a GtkScale indicator
On Fri, 2018-03-30 at 21:01 +0200, Stefan Salewski wrote:
> I have the impression there is no CSS property to make GtkScale
> slider
> smaller.
Finally I have a working solution. The trick is, that we have to set
margin also. Margin is negative in default, which does not work with
tiny min-width and max-width. margin is the size of the colored bar.
Here is the Nim code for a tiny slider, code for other languages should
be similar:
import gintro/[gtk, glib, gobject, gio]
proc appActivate(app: Application) =
let window = newApplicationWindow(app)
let scale = newScaleWithRange(Orientation.horizontal, 0.0, 100.0, 10.0)
let cssProvider = newCssProvider()
let data = "scale slider {min-width: 4px; min-height: 4px; margin: 0px}"
discard cssProvider.loadFromData(data)
let styleContext = scale.getStyleContext
assert styleContext != nil
addProvider(styleContext, cssProvider, STYLE_PROVIDER_PRIORITY_USER)
window.add(scale)
showAll(window)
proc main =
let app = newApplication("org.gtk.example")
connect(app, "activate", appActivate)
discard run(app)
main()
Note that this CSS code does affect only the widgets of your tool, not
other Gnome widgets. You may even name your widgets and then can set
CSS properties of single widgets.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reduce the size of a GtkScale indicator
On Thu, 2018-03-29 at 21:50 +0200, Bas Wassink wrote: > I kinda figured I had to go the CSS route, I have the impression there is no CSS property to make GtkScale slider smaller. I did a few tests yesterday, without a result. But I have to admit that for my screen it is already small. Maybe Mr Bassi will have an idea when he is back from vacation. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reduce the size of a GtkScale indicator
On Thu, 2018-03-29 at 18:02 +0200, Bas Wassink wrote:
> Any hints?
https://developer.gnome.org/gtk3/stable/chap-css-overview.html
grep -A100 GtkScale ~/.config/gtk-3.0/gtk-default.css
Well, I do provide a colored label example at
https://github.com/StefanSalewski/gintro
Starting from that one, it is easy to get a really big slider:
import gintro/[gtk, glib, gobject, gio]
proc appActivate(app: Application) =
let window = newApplicationWindow(app)
let scale = newScaleWithRange(Orientation.horizontal, 0.0, 100.0, 10.0)
let cssProvider = newCssProvider()
let data = "scale slider {min-width: 32pt; min-height: 32pt;}"
discard cssProvider.loadFromData(data)
let styleContext = scale.getStyleContext
assert styleContext != nil
addProvider(styleContext, cssProvider, STYLE_PROVIDER_PRIORITY_USER)
window.add(scale)
showAll(window)
proc main =
let app = newApplication("org.gtk.example")
connect(app, "activate", appActivate)
discard run(app)
main()
Yes, I know you want a tiny one. But setting nim-width, min-height to
small values does not decrease size, which is not really surprising, as
that are min and max values. So we have to search for other properties
-- maybe Mr Bassi or Mr Bader will tell us.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk4-query-immodules: command not found
On Sun, 2018-03-25 at 14:05 +0200, Stefan Salewski wrote: > /opt/gtk/bin $ LD_LIBRARY_PATH="../lib64" ./gtk4-demo > > (gtk4-demo:14466): GLib-GIO-WARNING **: 14:03:06.071: Can't find > module > 'dconf' specified in GSETTINGS_BACKEND > GLib-GIO-Message: 14:03:06.071: Using the 'memory' GSettings > backend. Your settings will not be saved or shared with other > applications. The reason seems to be that meson automatically installs latest glib, which does not contain dconf. Fix is: cd /opt/dconf-0.28.0 meson --prefix /opt/gtk builddir ninja ninja install After that, I can launch gtk4-demo as user: /opt/gtk/bin $ LD_LIBRARY_PATH="../lib64" ./gtk4-demo Seems to work, font size is correct. Fishbowl is fast, but I don't know if it is Vulkan or plain OpenGL. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk4-query-immodules: command not found
On Sun, 2018-03-25 at 13:43 +0200, Stefan Salewski wrote: > What may be the best way to fix this issue? Well, obvious PATH=$PATH:/opt/gtk/bin/ export PATH ninja install LD_LIBRARY_PATH="/opt/gtk/lib64" ninja install works, but then still I get tiny fonts with /opt/gtk/bin $ LD_LIBRARY_PATH="../lib64" ./gtk4-demo (gtk4-demo:14466): GLib-GIO-WARNING **: 14:03:06.071: Can't find module 'dconf' specified in GSETTINGS_BACKEND GLib-GIO-Message: 14:03:06.071: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
gtk4-query-immodules: command not found
Following GTK4 install into /opt/gtk from https://developer.gnome.org/gtk4/3.93/gtk-building.html I get for last step "ninja install" Running custom install script '/opt/gtk+-3.93.0/build-aux/meson/post- install.sh 4.0 4.0.0 /opt/gtk/lib64 /opt/gtk/share' Compiling GSettings schemas... Updating desktop database... Updating icon cache... Updating input method modules cache... /opt/gtk+-3.93.0/build-aux/meson/post-install.sh: line 20: gtk4-query- immodules: command not found Failed to run install script '/opt/gtk+-3.93.0/build-aux/meson/post- install.sh 4.0 4.0.0 /opt/gtk/lib64 /opt/gtk/share' FAILED: meson-install /usr/bin/python3.5 /usr/lib/python-exec/python3.5/meson --internal install /opt/gtk+-3.93.0/builddir/meson-private/install.dat ninja: build stopped: subcommand failed. I guess this may be the reason for that I get only tiny default fonts for gtk4 apps launched under gnome3 wayland. What may be the best way to fix this issue? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Testing GTK4 in /opt/gtk -- tiny fonts on HiDPI display
On Sat, 2018-03-24 at 21:19 +0100, Stefan Salewski wrote: > On Sat, 2018-03-24 at 19:50 +0100, Stefan Salewski wrote: > > Yesterday I tried for the first time GTK4 install as described in > > https://developer.gnome.org/gtk4/3.93/gtk-building.html > > > > > > Well, seems to be a wayland issue. > > Indeed a known one https://bugzilla.gnome.org/show_bug.cgi?id=790201 ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Testing GTK4 in /opt/gtk -- tiny fonts on HiDPI display
On Sat, 2018-03-24 at 19:50 +0100, Stefan Salewski wrote: > Yesterday I tried for the first time GTK4 install as described in > https://developer.gnome.org/gtk4/3.93/gtk-building.html > > Well, seems to be a wayland issue. When I log in in GDM with plain "Gnome" session, fontsize for GTK4-demo is fine. But when I log in with "Gnome under Wayland" (what is my default) I get tiny 11 point fonts only. Indeed in https://developer.gnome.org/gtk4/3.93/GtkSettings.html they say "On the X window system, this sharing is realized by an XSettings manager that is usually part of the desktop environment, along with utilities that let the user change these settings. In the absence of an Xsettings manager, GTK+ reads default values for settings from settings.ini files in /etc/gtk-4.0" So maybe it is intended to not work with wayland. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Testing GTK4 in /opt/gtk -- tiny fonts on HiDPI display
Yesterday I tried for the first time GTK4 install as described in https://developer.gnome.org/gtk4/3.93/gtk-building.html Worked well, and I can successfully launch gtk4-demo. On my 27 inch 4k monitor all gtk4 apps seems to have only 11 point font, which is very small and does not allow real testing. For my Gnome 3 GUI I have set a font scale of 1.9, but GTK4 seems not to use GTK3 font settings. I tried different font configs for GTK4, but no one gave a change. Is Font size still hard coded in GTK4? (The reason for my early GTK4 testing is, that I already consider gobject-introspection Nim support for GTK4, similar to https://github.com/StefanSalewski/gintro ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: background color for GtkTreeView
On Sat, 2018-03-10 at 14:26 +0100, codemusi...@gmail.com wrote:
> Hi there,
>
> I'm trying to change the background-color of a GtkTreeView by adding
> a
> css provider with the following style set:
>
> treeview { background-color: #fffae1; }
>
> Unfortunately this has the effect that the row selection color
> changes
> from the default blue to this particular background color as well.
>
> Note that I'm aware that I can change the background color of
> individual rows. However, I want to change the color of the entire
> widget including the whitespace.
>
> I can't figure out how to prevent the row selection color from
> changing
> as well.
>
> Any help would be greatly appreciated.
>
>
GTK3?
grep -C3 "treeview.view.selected" .config/gtk-3.0/gtk-default.css
-GtkTreeView-tree-line-width: 1;
-GtkTreeView-tree-line-pattern: '';
-GtkTreeView-expander-size: 16; }
treeview.view:selected:focus, treeview.view:selected {
border-radius: 0; }
treeview.view:selected:backdrop, treeview.view:selected {
border-left-color: #a5c8ec;
border-top-color: rgba(46, 52, 54, 0.1); }
treeview.view:disabled {
--
textview text selection:focus,
textview text selection, flowbox flowboxchild:selected,
spinbutton:not(.vertical) selection,
entry selection, modelbutton.flat:selected,
.menuitem.button.flat:selected, treeview.view:selected:focus,
treeview.view:selected, row:selected, calendar:selected {
background-color: #4a90d9; }
row:selected label, label:selected, .selection-mode
button.titlebutton, .view:selected:focus, iconview:selected:focus,
.view:selected, iconview:selected,
.view text:selected:focus,
--
I assume that after changing complete background, you have to set
background for selected again. Above #4a90d9 looks like that color. You
have to find out how to do it exactly yourself.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Is GtkSourceView available for Windows 10 ?
Thanks for that hint, I will add a note to the gintro tutorial. On Fri, 2018-03-02 at 13:32 -0500, Patrick Griffis via gtk-list wrote: > > A windows 10 user seems to manage to get gintro package installed > > on > > his windows 10, see > > > > https://github.com/StefanSalewski/gintro/issues/24 > > > > All the shipped examples seems to work indeed, but he had to skip > > GtkSource install (generating GObject-Introspection based bindings) > > because GTKSourceView dll may be missing. I can not find much about > > this issue with google. If GtkSourceView is intentionally not > > include > > in windows packages, then I will just skip that part for install > > script. > > Yes they already found MSYS2 which contains the packages: > https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gtkso > urceview3/ > > ___ > gtk-list mailing list > gtk-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Is GtkSourceView available for Windows 10 ?
A windows 10 user seems to manage to get gintro package installed on his windows 10, see https://github.com/StefanSalewski/gintro/issues/24 All the shipped examples seems to work indeed, but he had to skip GtkSource install (generating GObject-Introspection based bindings) because GTKSourceView dll may be missing. I can not find much about this issue with google. If GtkSourceView is intentionally not include in windows packages, then I will just skip that part for install script. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Full nimble support for gintro package (high level GTK3 Nim GUI) available
With latest nimble and nim a plain nimble install gintro should work now out of the box. (Well at least for 64 bit Linux and recent GTK 3.22 -- I can currently not test Windows, MAC or 32 bit Linux) The examples should compile and work with latest nim 0.17.3. Short tutorial at https://github.com/StefanSalewski/gintro For those not that familiar with Nim Programming language: https://nim-lang.org/ ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: centered and right justified label in the same line.
On Mon, 2018-02-26 at 09:16 +0100, Wojciech Puchar wrote: > How to do this in GTK 2. whatever i try i'm getting first label > centered > relative to space remaining after second label not to whole hbox. how > to > do this properly? > > That may be not that easy. Maybe try a hbox, which again contains 3 hboxes. 3 because so it may allow center the middle one. Then put your labels into some of these 3 boxes. Or you may try a table or grid with 3 columns. I think grid exists only for GTK3. Maybe someone other has a better solution. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: hints when keeping mouse cursor over widget
On Fri, 2018-02-23 at 14:17 +0100, Wojciech Puchar wrote: > Gimp can do this so GTK can do this but i cannot find how. > > > How to turn off text hints (help) when mouse pointer hovers over the > widget? > See https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-tooltip-text and https://developer.gnome.org/gtk3/stable/GtkTooltip.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_icon_theme_load_icon and GDK_SCALE=2 results in blurry icon
On Tue, 2017-10-03 at 17:28 +0400, Alexander Shaduri wrote: > I have a HiDPI Screen I also. 27 inch 4k display. I started also with scale of 2 to avoid tiny objects, but now I use scale=1 with larger fonts and I use some custom CSS to make vertical scrollbars a bit larger. Firefox can scale webpages well, so it is OK for me now. For your problem: Have you tried https://developer.gnome.org/gtk3/stable/GtkIconTheme.html#gtk-icon-theme-load-icon-for-scale There you will find a reference to https://developer.gnome.org/gtk3/stable/GtkIconTheme.html#gtk-icon-theme-load-icon-for-scale where notes about displays with high pixel densities exists. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do we get GTYPE from gobject introspection language bindings
On Fri, 2017-09-29 at 04:45 +, Gergely Polonkai wrote:
> As a side note, STRING probably refers to https://developer.gnome.org
> /glib/stable/glib-Strings.html which is a more OO string
> implementation. G_TYPE_STRING being gchararray is of more close
> relation with C strings (except it consists of gchars instead of
> chars.)
Yes, that can be the reason for my observation that I got a non zero
result for g-type-from-name("GSTRING").
I think guessing the other names is easier, it should be gint, gfloat
or widget names like GtkEntry.
I have added the listview example to the mini tutorial, see bottom of
https://github.com/StefanSalewski/gintro
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
How do we get GTYPE from gobject introspection language bindings
I am just preparing a listview example for the Nim GTK3 mini tutorial. I followed the Z-Code C example. Was not too difficult. But I got one problem: For working with listviews, we have to provide GTypes, which are numerical values. For C we have the macros like G_TYPE_STRING which for my box gives currently value 64. These values seems to be not directly supported by gobject-introspection. Seems to be no big problem, we may query the values by g-type-from-name(). https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#g-type-from-name For G_TYPE_STRING I assumed that name is "GSTRING" which gives indeed a non zero result from g-type-from-name(). But it is wrong. We can get the correct name by using g_type_name(G_TYPE_STRING). This gives "gchararray". And indeed, when I provide this name to g-type-from-name() then the Nim example works fine. But where should high level users find the corresponding G_TYPE names or values? Or is there another way to get G_TYPE values? I assume a static list of integers would not make much sense? Maybe you know how this is done in other languages with GTK bindings. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Flickering with Socket and Plug
On Sun, 2017-09-24 at 13:54 +0200, René Hansen wrote: > it starts flickering constantly I don't know what Socket and Plug is... But you seems to do the drawing completely wrong. Generally gtk_widget_queue_draw() is involved in the drawing process, that is that your timer does not do the drawing directly, but only invalidates the widget, which cause a indirect draw. You may find a few examples for this, one recent using plain C was contained in this thread: https://lists.cairographics.org/archives/cairo/2016-October/027791.html https://pastebin.com/in17XGjs ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to get a "traditional" file-chooser
On Fri, 2017-09-15 at 22:41 +0100, Emmanuele Bassi wrote: > Additionally, modify_bg() has never done anything about > sizing, Sometimes you seems to try very hard to misunderstand people? My English is not good, but I really think Chris Moller was refering only to the fact that modify_bg() was deprecated in GTK3 and does not work properly often when people try to use it. Changing colors is what beginners like to do. And they generally expect that only one simple function call is necessary to do it. With Google you can find many questions of people asking why modify_bg() or modify_fg() does not work as expected. Finding an example for a properly working solution for GTK3 is possible, but not as easy as it should be. To avoid getting such complains for the Nim bindings, I decide to give an example in the mini tutorial for the label widget: https://github.com/StefanSalewski/gintro I hope that is correct, it is based on a C version someone posted at stackoverflow. I know that modifying colors is not that easy in GTK3, as backgrounds can be gradients for example. And using arbitrary colors generally look not good for all themes. For me that is OK. But is there really no way to allow a one function() call option for kids and beginners? Well, should we really care about kids and beginners at all? As they will not be able to contribute something valuable -- only stupid questions. But the fact is, that most users start as kids or beginners with GUI toolkits or programming languages -- and some of them years later may do valuable contributions. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_signal_emitv -- where is it used in application code?
On Fri, 2017-09-15 at 12:25 +0100, Emmanuele Bassi wrote: > The g_signal_emitv() function is the vector-based function for > emitting signals in language bindings. > > The variadic argument version is a C convenience function, as > functions with variadic arguments are not introspectable. > > This is a typical pattern for any GObject-based library; for every > variadic argument function there should be a vector-based one that > can > be used by language bindings. > > Ciao, > Emmanuele. When I provide a Nim version of g_signal_emitv() -- how could I test it? I am still not aware of a (small) example in any language (C, Python, Ruby, ...) where it is used. With Google I found the Perl glue code, but still no test. https://github.com/GNOME/perl-Glib/blob/master/GSignal.xs ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
g_signal_emitv -- where is it used in application code?
https://developer.gnome.org/gobject/stable/gobject-Signals.html#g-signal-emitv For the most recent issue https://github.com/StefanSalewski/gintro/issues/8 I have absolutely no idea currently. Is g_signal_emitv() generally used in applications code, or is it used for library development (creation of new widgets for example) only. I have never emitted any signals by myself, not in C, not in Ruby and not in Nim. And I can find no examples of use of g_signal_emitv and other g_signal_emit functions currently -- outside of the GTK library code. Do you know an example application? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: One more Gobject Introspection issue
On Fri, 2017-09-15 at 10:28 +0100, Emmanuele Bassi wrote: > All API that takes a GtkIconSize should have a `type int` annotation. Thanks. I learned that already from the reply of Mr. Phil Clayton. Seems that some functions like gtk_toolbar_set_icon_size() do not yet have a `type int` annotation. Passing ints as parameters have the disadvantages, that people may try to pass true size like 64 and wonder why it does not work. I can remember someone who has done that indeed. And gtk-icon-size-register() https://developer.gnome.org/gtk3/stable/gtk3-Themeable-Stock-Images.html#gtk-icon-size-register seems to be deprecated now. I have a customer who is porting his GTK2 application to Nim GTK3 high level GTK API -- he reported that issue. Currently he has to convert the Nim enums to int when passing the parameters like IconSize.menu.ord where .ord does the conversion to int. I think I will let it as it is for now, thanks. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: One more Gobject Introspection issue
On Fri, 2017-09-15 at 09:57 +0100, Phil Clayton wrote: > Have a look at > https://bugzilla.gnome.org/show_bug.cgi?id=601425 Great, thanks. I had looked only into the list of gobject-introspection bugs mentioned at the bottom of this page: https://wiki.gnome.org/action/show/Projects/GObjectIntrospection?action=show=GObjectIntrospection ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
One more Gobject Introspection issue
GtkIconSize type is reported as plain gint, but it is an enum. For this function all is correct, see last line of code segment: This function sets the size of stock icons in the toolbar. You can call it both before you add the icons and after they’ve been added. The size you set will override user preferences for the default icon size. This should only be used for special-purpose toolbars, normal application toolbars should respect the user preferences for the size of icons. A #GtkToolbar The #GtkIconSize that stock icons in the toolbar shall have. But here, again see last line of code segment: Creates a #GtkImage displaying an icon from the current icon theme. If the icon name isn’t known, a “broken image” icon will be displayed instead. If the current icon theme is changed, the icon will be updated appropriately. a new #GtkImage displaying the themed icon an icon name or %NULL a stock icon size (#GtkIconSize) So ctype is GtkIconSize, but due to name="gint" I get from gobject- introspection only plain gint=int32. Unfortunately there exists a few functions with that bug, and it is some work fixing it manually. I will investigate if there is a way to get the ctype from gobject- introspection, but I think that that is not possible. I think the problem is in the C header files, I have seen something like (type int) for some function parameters with GtkIconSize data type. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtkdialog maximum size
On Wed, 2017-09-13 at 10:34 +, Rúben Rodrigues wrote: > Why are you saying that using a scrolled window with parts invisible > is > not user frindly? Because the user has to scroll :-) Of course having a scrolled window with active scrollbars can be necessary -- when there is really more content as fits on the screen. But it may be more user friendly to make widgets or text not too large, or to hide rarely used widgets. So all fits onto the screen. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkdialog maximum size
On Wed, 2017-09-13 at 10:59 +0100, Emmanuele Bassi wrote: > Why are you using a GtkDialog? You should be using a GtkWindow for a > complex UI. > > Additionally, the size of a top-level is given by its contents, > unless > you specify a size yourself. If your UI is too big, you'll have to > arrange it differently. For a plain Window he may use of course a GtkScrolledWindow. I am not sure if that would work for a dialog too, but I think so. But of course a scrolled window with parts invisible is not really user friendly... Ruben, what do you expect when contents do not fit onto screen? And have you solved your other problem with the two dialogs following each other? I have seen a long reply of somebody to your question -- did that helped you? Next question may be how to detect that content is too large for screen, and how to shrink content. Maybe check allocation for window first. And when larger than screen, maybe reduce text size, widget size or hide some widgets. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Pango library seems to be really hard for gobject-introspection?
On Sat, 2017-09-09 at 21:46 +, Emmanuele Bassi wrote: > Boxed types use g_boxed_free() to release resources, and > g_boxed_copy() to copy them: > https://developer.gnome.org/gobject/stable/gobject-Boxed-Types.html > > Ciao, > Emmanuele. Yes I know :-) But from https://developer.gnome.org/pango/stable/pango-Fonts.html#pango-font-description-new PangoFontDescription is a boxed type (from Object Hierarchy), and we shall use pango_font_description_free() for freeing. Do you suggest just using g_boxed_free() instead? I don't think that is right? What I found out in the last few hours at least: Pango data types which needs a ...destroy() function for freeing seems to be mostly marked with introspectable="0". So my current impression is, that for all the data types which I "see" from gobject introspection with transfer- ownership="full", I have to use ...free() for freeing. For other data types, which needs ...destroy() I have to manually create the glue code, when they should be needed at all. But there are also data types like PangoFontMetrics which may need an unref instead -- maybe that ones are used internally only. But pango is really hard to understand. For example https://developer.gnome.org/pango/stable/pango-Layout-Objects.html#pango-layout-get-line For that we have transfer == none, but we can modify the result, and we can ref and unref the result. To make it even more complicated there is also pango_layout_get_line_readonly() ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Pango library seems to be really hard for gobject-introspection?
First I noticed that for pango_font_description_from_string() >From /usr/share/gir-1.0/Pango-1.0.gir we know that transfer- ownership="full" so we have to free it in our language bindings. But how to guess the function for freeing? For gobject there is generally a plain g_object_unref() necessary, and there is even g_object_info_get_unref_function () available. Well PangoFontDescription is Boxed type, does that help? For all the data types with transfer-ownership="full" there seems to exist in /usr/share/gir-1.0/Pango-1.0.gir: pango_attribute_destroy(), pango_attr_list_unref(), pango_attr_iterator_destroy(), pango_color_free() and more. Well, my current guess would be to parse all methods of the pango data types and use the one which contains free or destroy or unref in its name? But that sounds a bit strange. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wait cursor animation does not work properly
On Tue, 2017-09-05 at 08:50 +0200, Stefan Salewski wrote: > I will follow all your advice and start a new thread for the chess > engine to return the reply move. Well yes, but not now... For now I have pushed a still blocking release to github: https://github.com/StefanSalewski/nim-chess4 I think the GTK code looks not too bad now: https://github.com/StefanSalewski/nim-chess4/blob/master/board.nim Creating a thread for the chess engine would be some work, and currently I am more interesting in testing the high level Nim bindings and providing some example code. I have also added a cairo animated drawing example to the tutorial, see bottom of https://github.com/StefanSalewski/gintro It is based of a C example someone recently posted at cairo mailing list. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Show dialog after hide another
On Fri, 2017-09-08 at 11:11 +, Rúben Rodrigues wrote: > Please!! > > Help.. Well, I guess what you want is displaying a message dialog without prior user actions. Maybe you can emit a signal to do that? I don't know, have never needed that. Maybe you can just modify your first dialog, display another text? Or, maybe what you really want is something like the GtkAssistant, I think that one is something that guides a user through a longer sequence of actions. Finally, you misses to tell us if you are using mainline GTK3 or a different version, which OS, and what your great FOSS application on which you are working is. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Wait cursor animation does not work properly
On Mon, 2017-09-04 at 22:39 +0100, Chris Vine wrote: > If Stefan needs any further assistance I think he needs to explain > what > his issue actually is. Well, my first posting in this thread seems to indicate a real issue, as Mr cecas...@aol.com confirmed. Animation does not continue when mouse pointer is moved out of the widget and back again. Maybe that is a Wayland problem -- when it is I assume that it will be fixed some day. Maybe it is restricted to my dev-libs/wayland-1.13.0::gentoo For the g_idle_add(): As Mr E. Bassi explained, there is a different behaviour in Wayland, cursor animation does only work when main thread is idle. I will follow all your advice and start a new thread for the chess engine to return the reply move. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wait cursor animation does not work properly
On Sun, 2017-09-03 at 16:54 +0100, Emmanuele Bassi wrote: > You're blocking the toolkit's main loop, here. If your application > does this, it's broken and needs to be fixed - regardless of what the > cursor looks like. > > The cursor is rendered by the Wayland compositor, but the animation > is > performed by the toolkit, i.e. it's the toolkit that uploads the > cursor's data to the compositor. Of course you are right that using g_idle_add() is still blocking the GUI. But I think that having an animated Busy cursor makes only sense at all when it is animated while a program is doing some heavy calculation. So the animated cursor is indeed an indication for a short blocked period. My chess engine takes only a few seconds to calculate the next move, so creating an own thread is some overkill. What I need: User has done his move, so update display, indicate that computer is "thinking" for a few seconds, and then update display again. I think that should be possible with g_idle_add(). Instead of the busy pointer I may set a message to the window title. Later I may consider indeed using a separate thread -- I did that already one year ago for my Ned Nim editor for communicating with the nimsuggest process, but I can not remember details currently. Doing it really properly may be not easy for a chess engine, as the human player should be able to interrupt the computer thinking at arbitrary times. Unfortunately there exist very few examples, and some are more Python related like https://stackoverflow.com/questions/16934087/how-to-do-background-task-in-gtk3-python ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wait cursor animation does not work properly
On Sun, 2017-09-03 at 17:23 -0400, cecas...@aol.com wrote: > With a jhbuild of GTK3.22 I get a wrist watch type clock cursor for > "wait" that doesn't have any animation. Thanks for testing. So problem is not my local Gentoo box, but GTK 3.22. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wait cursor animation does not work properly
On Sun, 2017-09-03 at 16:54 +0100, Emmanuele Bassi wrote: > You're blocking the toolkit's main loop, When I add a background function with g_idle_add() I am blocking the GTK main loop? Well I just wanted to avoid that. But even without use of g_idle_add() the animation stops, when I move the cursor out of the window and back, see my first example. So there is a GTK bug. My initial chess GUI was this: https://github.com/StefanSalewski/nim-chess3/blob/master/board.nim I know that it was really ugly, I was told that while gtk3.eventsPending(): discard gtk3.mainIteration() is really bad design. But that first draft was basically only a test of the low level Nim GTK wrapper, and it was working six months ago. It is still working, but mouse cursor is not animated any longer. For user input, I was going to use a basic state maschiene -- state advances by each user mouse click. Response of computer is more difficult, I was going to use g_idle_add() to run computer chess engine in the background. But maybe I should use a own task/process? (Which may be a problem again, as GTK is single threaded?) Unfortunately, for such use cases there are nearly no GTK example available. Have done some Goggle search already... ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wait cursor animation does not work properly
On Sun, 2017-09-03 at 16:43 +0200, Stefan Salewski wrote:
> Since a few months I have observed that for my chess game the mouse
> pointer/cursor animation stopped working properly.
Well, I have added the g_idle_add() problem also.
When I move the mouse pointer the first time into the button widget,
animation works fine. But when I click on the button, animation stops
while idle function is active, which is 5 seconds. After that period
animation works fine again.
But when I move the pointer out of the window and back again, animation
is stopped and will not start again.
May that be a Wayland problem? I do not really think so, but I am not
really sure.
// gcc t.c `pkg-config --libs --cflags gtk+-3.0`
#include
//include
#include
static gboolean
idle_func(gpointer data)
{
int i;
i = 0;
while (i < 9)
{
g_usleep(100);
i++;
g_printf("busy\n");
}
return G_SOURCE_REMOVE;
}
static void
button_clicked (GtkButton *button,
gpointer user_data)
{
const char *old_label;
char *new_label;
old_label = gtk_button_get_label (button);
new_label = g_utf8_strreverse (old_label, -1);
gtk_button_set_label (button, new_label);
g_free (new_label);
g_idle_add(idle_func, NULL);
}
static void
activate (GtkApplication *app,
gpointeruser_data)
{
GtkWidget *window;
GtkWidget *button;
GdkDisplay *display;
GdkCursor *cursor;
window = gtk_application_window_new (app);
gtk_window_set_title (GTK_WINDOW (window), "GNOME Button");
gtk_window_set_default_size (GTK_WINDOW (window), 250, 50);
button = gtk_button_new_with_label ("Click Me");
gtk_container_add (GTK_CONTAINER (window), button);
g_signal_connect (GTK_BUTTON (button),
"clicked",
G_CALLBACK (button_clicked),
G_OBJECT (window));
gtk_widget_show_all (window);
display = gdk_display_get_default();
cursor = gdk_cursor_new_from_name(display, "wait");
gdk_window_set_cursor(gtk_widget_get_window(window), cursor);
}
int
main (int argc, char **argv)
{
GtkApplication *app;
int status;
app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
status = g_application_run (G_APPLICATION (app), argc, argv);
g_object_unref (app);
return status;
}
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Multi page widgets in Gtk
On Sun, 2017-09-03 at 13:42 +0100, Mike Martin wrote: > For one of my apps I want to setup a multi page widget with next > previous > navigation. Have you tried https://developer.gnome.org/gtk3/stable/GtkAssistant.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Wait cursor animation does not work properly
Since a few months I have observed that for my chess game the mouse
pointer/cursor animation stopped working properly.
Yesterday I tried cleaning up the code for moving the game GUI to the
new high level Nim GTK GUI, but I was unable to get it working.
When I moved the busy-cursor out of the application window and back
again, animation stops. Same if I used g_idle_add() call -- animation
stops as long as idle function (computer chess engine) is active.
I was not able to find recent bug reports about this, so I am not sure
if I am doing something wrong (do not really think so.)
So I just grabbed a C demo application from the gnome side and added
set cursor stuff. There is no idle function currently, but the problem
occurs already when I move the animated cursor out of the window and
back again. Animation stops.
This is for gtk+-3.22.16:3::gentoo GDM display manager logged in under
WAYLAND.
// gcc t.c `pkg-config --libs --cflags gtk+-3.0`
#include
static void
button_clicked (GtkButton *button,
gpointer user_data)
{
const char *old_label;
char *new_label;
old_label = gtk_button_get_label (button);
new_label = g_utf8_strreverse (old_label, -1);
gtk_button_set_label (button, new_label);
g_free (new_label);
}
static void
activate (GtkApplication *app,
gpointeruser_data)
{
GtkWidget *window;
GtkWidget *button;
GdkDisplay *display;
GdkCursor *cursor;
window = gtk_application_window_new (app);
gtk_window_set_title (GTK_WINDOW (window), "GNOME Button");
gtk_window_set_default_size (GTK_WINDOW (window), 250, 50);
button = gtk_button_new_with_label ("Click Me");
gtk_container_add (GTK_CONTAINER (window), button);
g_signal_connect (GTK_BUTTON (button),
"clicked",
G_CALLBACK (button_clicked),
G_OBJECT (window));
gtk_widget_show_all (window);
display = gdk_display_get_default();
cursor = gdk_cursor_new_from_name(display, "wait");
gdk_window_set_cursor(gtk_widget_get_window(window), cursor);
}
int
main (int argc, char **argv)
{
GtkApplication *app;
int status;
app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
status = g_application_run (G_APPLICATION (app), argc, argv);
g_object_unref (app);
return status;
}
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Preferred height/width error message
On Sun, 2017-07-23 at 17:46 +0100, Mike Martin wrote: > Gtk version 3.22 I see a similar message for evince pdf viewer whenever I use it since some months. But I have no idea for the reason unfortunately (evince:5623): Gtk-WARNING **: Allocating size to EvSidebar 0x12dd6c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK's interfaces and language bindings
On Thu, 2017-07-20 at 13:44 +0200, Nicola Fontana wrote: > I see interfaces as a "contract" that (1) enforces an object > to implement some feature (properties and/or methods) and > consequently (2) gives the users a common API that can be used > across unrelated objects. Thanks for your explanations. I have just uploaded the extended Nim binding generator -- an example for styling widgets with CSS is located at the bottom of the README. https://github.com/StefanSalewski/gintro http://ssalewski.de/gintroreadme.html ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
GTK's interfaces and language bindings
Recently someone tried to style a widget using CSS, https://github.com/StefanSalewski/gintro/issues/2#issuecomment-316167963 and so I discovered that there is still some labor for me... Before I start coding, maybe it is better to verify my understanding of the gobject interfaces... For example, we have https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-style-context-add-provider which may be called from C like gtk_style_context_add_provider(gtk_widget_get_style_context(window), GTK_STYLE_PROVIDER(cssProvider), GTK_STYLE_PROVIDER_PRIORITY_USER); So the second parameter is of type GtkStyleProvider, which is an interface. GtkCssProvider provides that interface, so we can pass a variable of that type. GTK_STYLE_PROVIDER() is basically only a cast, a re-interpretation of the bit pattern, maybe with additional security checks. As we generally do not want such casts in higher level languages, we may just provide an additional function with the same name which accepts a GtkCssProvider. For this special case that is clear, and already tested. So I assume, that for all functions which has interfaces as parameters, I can just pass all objects (gobjects) which provides that interface? I even guess hat interfaces are fully abstract entities, so we will never pass an instance of an interface, but always only objects providing the interface. So we have only to provide functions which can accepts all the objects providing the that interface, but we do not really need functions which would accepts the interface parameter type itself? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject introspection and cairo?
On Sat, 2017-07-15 at 18:21 +0200, Nicola Fontana wrote: > They have been included in gobject-introspection 1.53.2, released > on may: > > https://git.gnome.org/browse/gobject-introspection/log/ Fine. My Gentoo box has still dev-libs/glib-2.50.3-r1:2::gentoo I will try to grab the lastest and prepare cairo bindings from that. While all the other true Nim gobject-introspection bindings are generated on the local box of the users during install, I have to ship a prebuilt bindings file for cairo, so it is no problem when most users do not yet have latest gobject-introspection. Thanks, Stefan Salewski ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject introspection and cairo?
On Tue, 2017-05-09 at 17:05 +0200, Nicola Fontana wrote: > Il Tue, 09 May 2017 16:39:10 +0200 Stefan Salewski <m...@ssalewski.de > > scrisse: > > > I am currently working again on the gobject introspection based > > bindings for Nim language (https://github.com/StefanSalewski/nim-gi > > ). > > > > And I wonder why there is only minimal support for cairo -- > > /usr/share/gir-1.0/cairo-1.0.gir is minimal. > > Hi Stefan, > > not so long ago Emmanuele accepted a few patches that improves > this situation: > > https://bugzilla.gnome.org/show_bug.cgi?id=743364 > > No idea how long does it take to have that upstream. > > Ciao. Is it already known when these patches will be available for ordinary users? The gobject-introspection based files for my current Nim bindings seems to work already not too bad (https://github.com/StefanSalewski/gintro) so I should try to provide cairo bindings soon as well. Creating all manually is of course some additional work, so I would hope that your patches can save me some labor. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
GDM wayland login -- display shuts down and is hard to get on again
Since a few months I have GTK 3.22 on my gentoo box, and so I tried to log in with Wayland support from the graphical GDM display manager. Works all fine. But one problem is, that the display is shut down after a few hours sometimes. Initially I had the impression that wayland does that shut down. But the Gnome screensaver related settings are disabled, and I never saw that shutdown without wayland. My current impression is: Monitor shuts down after some hours to save energy, wayland display driver detects this and shuts down the display driver in PC to save even more energy. I think that is the right idea, as the same seems to occur also when I power off the monitor while the PC is still running. Getting the display on again is really hard. After much testing a found one method that works most of the time: Ensure monitor is powered off. Then press Ctrl-ALT-F3. Wait about one second and switch on the monitor. Most of the time I can get a visible terminal 3 this way and can switch back to Gnome GUI with Alt-F2. May there exist a better solution? A secret wakeup key? Or useful search terms for search engine? Monitor is connected via USB-C to PC, PC is Intel NUC skull canyon. PS: For my previous post, I really forgot to give the explicit link to the git repository. It is https://github.com/StefanSalewski/gintro Fortunately that link was contained in the git clone expression already. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
High level GI-based GTK3 bindings for the Nim programming language
I have uploaded the first public release of the high level GObject- Introspection-based GTK3 bindings for the Nim programming language yesterday. If you have GTK3 and Nim compiler installed you may try them. Install is currently cd /tmp git clone https://github.com/stefansalewski/gintro cd gintro nimble prepare nimble install In the future a plain "nimble install" for the Nim package manager should work, but currently the initial git clone is necessary. I have no idea if there is a change that that works on windows or MacOSX, but at least for 64 bit Linux with GTK 3.22 chances are good that install process works. The git README already contains a small tutorial, but that is more for Nim novices. People familiar with any GTK bindings or plain C GTK should know how the Nim bindings can be used -- it may look a bit like Python code. Of course there is still much work to do for testing and improving, but at least the few mostly randomly selected examples seem to work not bad. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
gtk_container_remove may generate some noise for a GC
https://github.com/GNOME/gtk/blob/master/gtk/gtkcontainer.c
void
gtk_container_remove (GtkContainer *container,
GtkWidget*widget)
{
g_return_if_fail (GTK_IS_CONTAINER (container));
g_return_if_fail (GTK_IS_WIDGET (widget));
g_object_ref (container);
g_object_ref (widget);
g_signal_emit (container, container_signals[REMOVE], 0, widget);
_gtk_container_accessible_remove (GTK_WIDGET (container), widget);
g_object_unref (widget);
g_object_unref (container);
}
Well, now I understand the origin of some debug messages I may get from
my Nim bindings code.
Why has gtk_container_remove() to call ref/unref on widget and
container? My assumption was, that gtk_container_remove() is an atomic
action. And GTK is single threaded? Is that already preparation for a
multi-threaded GTK4?
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_object_add_toggle_ref
On Sun, 2017-06-25 at 10:59 +0100, Emmanuele Bassi wrote: > I very much doubt anybody here has knowledge of toggle reference and > language bindings. Yes, I guess that is true, the original authors seems all to be retired. For IRC or devel list, I fear situation is not really better, and I do not really want to make noise there, the few remaining developers may have to do more important stuff. > All GC language bindings will immediately sink the floating reference, > as it makes memory management harder for them (it's a C feature, after > all). So my suggestion is to immediately and automatically sink the > floating reference inside your wrapper around g_object_new() before it > returns the instance to the non-C side. That is an interesting hint. Indeed I did that in my first draft about a year ago, before I discovered g_object_add_toggle_ref() function. Of course it makes sense to use it in combination. At least basically my Nim wrapper is working already -- maybe for details I will have to look at wrappers for other languages. Maybe I should consider contacting the Rust developers, as Rust is also a compiled language, and they have some GTK bindings. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Floating references
Some years ago I read about floating references as described in https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html Of course that makes sense. Newly created objects get ref count 1, but are floating. If they get put into a container element, floating ref is converted to ordinary ref, and ref count stays at 1. But I was wondering, why for newly created objects ref count is not just zero, so when the element is put into a container it is just increased to one. So there must be a reason why it can not work this way. Of course when ref count drops to zero the element is deleted. But when a newly created element just has ref count zero, where is the problem? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_object_add_toggle_ref
On Sat, 2017-06-03 at 15:37 +0200, Stefan Salewski wrote:
What is a bit strange is
void
g_object_add_toggle_ref (GObject *object,
GToggleNotify notify,
gpointer data)
{
ToggleRefStack *tstack;
guint i;
g_return_if_fail (G_IS_OBJECT (object));
g_return_if_fail (notify != NULL);
g_return_if_fail (object->ref_count >= 1);
g_object_ref (object);
So after a call of g_object_add_toggle_ref() ref_count of an object is
always greater or equal to two? But how can now that value drop ever
again below 2? When a new references is added, it increases, and when
that references is removed, the value is decreased. But never below 2
this way? It is a bit confusing indeed.
More confusing is, that g_object_ref_sink () seems to exist since
gobject release 2.10, while g_object_add_toggle_ref () seems to exists
already since 2.8.
And, for my understanding of English wording, the documentation of
g_object_ref_sink() contradicts even itself:
https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type
.html#g-object-ref-sink
"Increase the reference count of object
, and possibly remove the
floating reference, if object
has a floating reference.
In other words, if the object is floating, then this call "assumes
ownership" of the floating reference, converting it to a normal
reference by clearing the floating flag while leaving the reference
count unchanged. If the object is not floating, then this call
adds a new normal reference increasing the reference count by one."
I assume, that the second part is correct. Maybe the first sentence
should be something like "Increase the reference count of object
, OR possibly"
So it will be not that easy to get fully working Garbage Collector
support.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
g_object_add_toggle_ref
My high level Nim wrapper (https://github.com/StefanSalewski/nim-gi2)
is indeed basically working.
Currently I am using g_object_add_toggle_ref() and
g_object_set_qdata(). The first for the garbage collection tasks, and
the later for retrieving the proxy object from the associated GTK
GObject, for example when functions like gtk_widget_get_parent() are
used. That seems to work, but I have the feeling of some redundancy.
Both gobject functions are passed the address of my proxy object. But
g_object_add_toggle_ref() seems to offer no support to get the address
back, that is why I use additional g_object_set_qdata() which allows me
to get back the proxy address with g_object_get_qdata().
proc gtk_button_new*(): ptr Button00 {.
importc: "gtk_button_new", libprag.}
proc newButton*(): Button =
new(result, finalizeGObject)
result.impl = gtk_button_new()
GC_ref(result)
g_object_add_toggle_ref(result.impl, toggleNotify, addr(result[]))
assert(g_object_get_qdata(result.impl, Quark) == nil)
g_object_set_qdata(result.impl, Quark, addr(result[]))
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Close button in GtkNotebook
On Sun, 2017-05-28 at 16:08 -0300, Augusto Fraga Giachero wrote: > I've been playing with Glade and GtkNotebook for while, and I > couldn't > figure a way to enable the close button on the tabs I guess what you want is what gedit does with the tabs? The gedit code has been modified a few times in the last years, I am currently using code from GTK 3.20 in my Nim editor. See # from 3.20 gedit-documents-panel.c ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GObject introspection and cairo?
I am currently working again on the gobject introspection based bindings for Nim language (https://github.com/StefanSalewski/nim-gi). And I wonder why there is only minimal support for cairo -- /usr/share/gir-1.0/cairo-1.0.gir is minimal. Of course cairo is not gobject based, but is that the real problem? I think glib is not gobject based too? Of course cairo interface is not large, so I can used the c2nim generated cairo bindings from https://github.com/ngtk3/nim-cairo and adapt it manually. But it would be nicer with direct introspection support -- not only for Nim, but also for other gi based bindings like Ruby, Python, Rust, Crystal and such I assume? And a not directly related remark: nim-chess3 is now available -- but it uses still the c2nim generated GTK 3.20 bindings. Maybe next winter I will replace that basic GUI with a real one. https://github.com/StefanSalewski/nim-chess3 ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gnome 3.22 Wayland is eating my chess pieces (unicode chess font)
On Mon, 2017-04-10 at 12:28 +0200, Stefan Salewski wrote: > I will try that soon. Yes, works fine: var w, h: cint #width: cint = widget.parentWindow.width #height = widget.parentWindow.height width = getAllocatedWidth(widget) height = getAllocatedHeight(widget) ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gnome 3.22 Wayland is eating my chess pieces (unicode chess font)
On Mon, 2017-04-10 at 11:07 +0100, Emmanuele Bassi wrote: > allocated size of > your widget Thanks. I think that is gtk_widget_get_allocation() for GTK3 as mentioned in http://stackoverflow.com/questions/2675514/totally-fed-up-with-get-gtk-widget-height-and-width I will try that soon. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gnome 3.22 Wayland is eating my chess pieces (unicode chess font)
On Mon, 2017-04-10 at 10:37 +0200, Stefan Salewski wrote:
> Any ideas?
Well, maybe the problem is not the font dimensions, but the window
itself.
The size calculations occur in
https://github.com/ngtk3/nim-chess2/blob/master/board.nim
proc drawIt(cr: cairo.Context; widget: Widget) {.cdecl.} =
const
Font = "Sans 64"
var
w, h: cint
width: cint = widget.parentWindow.width
height = widget.parentWindow.height
I can not remember why size calculation was based on
https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-get-parent-window
I guess I found a hint with Google, it may be related to window
decorations of window managers.
When I set Window size with
window.setDefaultSize(800, 800)
I get different results for wayland and X:
X:
widget.parentWindow.width 800
widget.parentWindow.height 800
Wayland:
widget.parentWindow.width 852
widget.parentWindow.height 894
I am not yet sure that this is the real problem, maybe both results are
just right?
But we need a solution which works for both, X and Wayland.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Gnome 3.22 Wayland is eating my chess pieces (unicode chess font)
Some days ago my Gentoo box finally updated to Gnome 3.22. First surprise: GtkSourceView ignores Text Scaling settings -- seems to be a well known bug: https://bugzilla.redhat.com/show_bug.cgi?id=1382840 Not a real problem, but surprising. Today I logged in using wayland session, selected by gears menu of GDM login screen and launched my chess game. I got this: http://ssalewski.de/tmp/nimchesswayland.png When I log out and in again with ordinary Gnome X session all is fine again as in https://github.com/ngtk3/nim-chess2 The cutoff effect is large for a small window, and decreases for a very large window. So there seems to be a fixed wrong offset in font glyph size? I have still no real idea, and I wonder why wayland can make a difference at all for pango font rendering. Any ideas? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Input event reduction
On Thu, 2017-03-30 at 10:21 +0100, Emmanuele Bassi wrote: > g_idle_add() or, better yet, g_main_context_invoke(). Thanks. While I can remember have read your explanations somewhere already, I really missed that g_main_context_invoke() function. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Thu, 2017-03-30 at 11:10 +0200, Nicola Fontana wrote:
>
>
> As said you can leverage the main loop and unroll yours, e.g.:
>
> gboolean my_idle_callback()
> {
> gint n;
> for (n = 0; n < 100; ++n) {
> ...
> }
> return FALSE;
> }
>
> should become:
>
> gboolean my_unrolled_idle_callback()
> {
> static gint n = 0;
> ...
> ++n;
> return n < 100;
> }
>
> Depending on your use case, the above could or could not be
> possible.
>
Ah yes, that is an interesting idea.
> >
> > So I have to go back to my initial idea -- create a thread which
> > gets a
> > message for each "changed" signal, and then calls an idle function
> > only
> > for the last message in the queue each. I have to use
> > gdk_threads_add_idle() then.
>
> This is probably the cleanest solution, although I don't
> understand why you would have to use gdk_threads_add_idle().
I think gdk_threads_add_idle() is the recommended way to update the GTK
GUI from inside a second thread. I am doing it in the current version
of the editor already for querying and displaying extended symbol
information, see https://github.com/ngtk3/NEd
Here is where gdk_threads_add_idle() was suggested:
https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
"You can schedule work in the main thread safely from other threads by
using gdk_threads_add_idle() and gdk_threads_add_timeout()"
>
> >
> > The task of that idle function in my current use case would be to
> > get
> > highlight syntax information from the IDE process called nimsuggest
> > and
> > then to apply the corresponding tags to gtksource textbuffer.
>
> IMO it is essential to split your code in two parts: (1) gathering
> the highlight information and (2) applying it to the textbuffer.
Yes, that was my thoughts too. It would imply some additional code, but
may be the best solution.
>
> (1) can be run entirely in the working thread (hence non-blocking)
> while (2) must be implemented as a callback to be run in the GTK+
> thread. I cannot believe (2) takes tenths of second.
>
> When you are ready from (1) you can spawn the idle callback with
> g_source_attach()... no needs for gdk_threads_add_idle(). In the
> following StackOverflow answer I provided an example in C:
>
> http://stackoverflow.com/questions/27950493/safety-of-using-pthreads-
> in-gtk2-0-application#27990662
>
Thanks for that suggestion, I will look at the stackoverflow example.
And indeed, applying the text tags to the gtksource buffer is finally
the only critical part. I dont know how fast that really is, I would
assume that it takes less than 50 ms, what would be fine. If it really
is slow, I may split it in multiple parts/calls.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Thu, 2017-03-30 at 09:38 +0200, Stefan Salewski wrote: > Currently I wonder if the call of gtk3.mainIteration() inside the > idle > function is possible and if it would help updating the display. In my > first draft of the Nim toy chess I used something like this > > while gtk3.eventsPending(): discard gtk3.mainIteration() Yes, that has an effect, it seems to allow GUI redraw, but keyboard input remains sluggish. If I add additional a sleep() function call keyboard seems to react better. But of course that is no real solution, so I have to test the thread idea next. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Wed, 2017-03-29 at 23:26 +0200, Nicola Fontana wrote: > > > idle functions do *not* run in the background so if you don't > release the CPU you will experience what you described. > > AFAIK all the GMainLoop code is single-threaded hence, as a > consequence, you will block the UI whenever the CPU is busy > running your code, being it inside a signal handler, a timeout > function or (as in your case) an idle function. > > Just avoid loops when you know they are expensive. Instead > leverage the cyclic nature of GMainLoop for iterating over your > code, i.e. by respawning your idle function as much as needed. > In that case it is really a bad idea to have a outer loop in that idle function :-( So I have to go back to my initial idea -- create a thread which gets a message for each "changed" signal, and then calls an idle function only for the last message in the queue each. I have to use gdk_threads_add_idle() then. The task of that idle function in my current use case would be to get highlight syntax information from the IDE process called nimsuggest and then to apply the corresponding tags to gtksource textbuffer. Unfortunately that may take a few hundred milliseconds for each full update. Currently I wonder if the call of gtk3.mainIteration() inside the idle function is possible and if it would help updating the display. In my first draft of the Nim toy chess I used something like this while gtk3.eventsPending(): discard gtk3.mainIteration() to avoid display freeze. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Wed, 2017-03-29 at 16:47 +0200, Stefan Salewski wrote: > On Wed, 2017-03-29 at 09:42 +0200, Stefan Salewski wrote: > > > > It is still the old problem: > > Well, after some thinking I have the feeling that it may work with > only > an idle function, so no separate thread and message passing is > necessary: The callback set a flag indicating that there is work to > do, > and calls the idle function unless the idle function is still > working. > That idle functions has an outer loop, which tests the flag and > returns > if unset. Otherwise it clears the flag and does the work. Will test > soon... > Yes, basically that works fine. Problem is the idle function added with https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add I have the strong feeling, that the provided function is not running silently in the background, but it is just called at some point and then blocks user input until the function terminates. At least, when that function is added with g-idle-add on GtkTextBuffer changed signal and that functions does only a delay of 2000 ms, then for that time user input into text buffer is blocked. That was not what I expected. And it is bad, user input becomes a bit sluggish. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Wed, 2017-03-29 at 09:42 +0200, Stefan Salewski wrote: > It is still the old problem: Well, after some thinking I have the feeling that it may work with only an idle function, so no separate thread and message passing is necessary: The callback set a flag indicating that there is work to do, and calls the idle function unless the idle function is still working. That idle functions has an outer loop, which tests the flag and returns if unset. Otherwise it clears the flag and does the work. Will test soon... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: SpinButton size
On Mon, 2017-03-27 at 14:23 +, Rúben Rodrigues wrote:
> hi guysm
>
> it's possible to change size of spinbuttons? In touchscreen mode
> spinbutton are still small.. We can change it's size with css
> provider?
>
>
That may be possible...
I found some example code in gedit C sources for changing widget sizes,
that code has changed from GTK version to GTK version. For 3.20 I have
working code like:
# from 3.20 gedit-documents-panel.c
let closeButton = button(newObject(typeButton, "relief", ReliefStyle.NONE,
"focus-on-click", false, nil))
let context = closeButton.getStyleContext
context.addClass("flat")
context.addClass("small-button")
let icon = newThemedIconWithDefaultFallbacks("window-close-symbolic")
let image: Image = newImage(icon, IconSize.MENU)
objectUnref(icon)
closeButton.add(image)
discard gSignalConnect(closeButton, "clicked", gCallback(closeTab), scrolled)
Well, that is not for spin button, but ordinary button. And again you
did not said if you want a solution for GTK2 or GTK4 on macosx.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Input event reduction
Well, I think I have asked this already some years ago at gtk-list. (And I spent some hours experimenting with stuff like event_pending() and such, without success.) It is still the old problem: We have input events, for example keystrokes, and a function that can only process a few events per second. What we want: If there are more than one event of this type pending (in the queue) than discard all but the last one. That seems to be really hard in GTK3. One solution, which is used in the NEd Nim editor: Create a separate task, send the events though a channel to that task. That channel behaves like a queue, so the task can discard events easily and process always only the last one. Problem is, that GTK is not thread safe, so that task can not do GUI update itself, but has to use an Idle_Add function. All that works fine, but that is more than 10 lines of code for such a trivial problem. Currently I get the "changed" signal of a GTk Text Buffer -- when the user types fast, there may be up to ten function calls per second initiated. Processing these realtime is still possible on a fast CPU, but to save resources (battery power for example) it would be better to drop a few events when there are many, but always process the last one. (Task here is smart syntax check or syntax highlight, so the last input is always what matters most.) Timer events would be an option, but that would imply a permanent delay. What we want instead is immediate reaction when there are input events. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re-drawing GtkDrawingArea surface on motion-notify-event
On Sun, 2017-03-19 at 22:12 +, Marcin Kolny wrote: > I'd like to write very simple application for drawing lines. You can restrict all drawing operations to a rectangle enclosing your line. For each move with button pressed, fill that rectangle with background color and then draw the line with foreground color. Or, you may save the old line start and end points and paint that old line with background color before drawing the new line. I think there is not much benefit for using an temporary surface for this use case. For more complicated graphics it can become a bit slow indeed -- I once tried it for my schematics editor -- there I used a bounding box for all the graphical elements, when one element is moved, I had to draw its background and then all other elements overlapping with that background element. Using OpenGl may be faster and easier, because you can fast just redraw all. I think GTK3 now has a gl-area widget. The problem with Gl is that it is basically more for drawing triangles than for drawing lines... ___ 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 change GTK+3 label color dynamically
On Thu, 2017-03-16 at 09:55 +, Rúben Rodrigues wrote: > Hi, > > THanks. This is dynamically? I need in c language if possible :S > > Thanks Yes. The example https://github.com/ngtk3/nim-gtk3/blob/master/test/colors.nim is dynamically, I used it to generate some color schemes. Entered color hex value in a text entry widget, and that color was applied. As I said, it was working for 3.18. I think for 3.20 and above some CSS names have changed, I had not the time to really investigate that. I have no C code currently, I think my Nim code was inspired by Python code, but I have no link to that python code currently. For C it is the same pattern -- generate a CSS string and apply it. ___ 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 change GTK+3 label color dynamically
On Wed, 2017-03-15 at 15:11 +, Rúben Rodrigues wrote: > Hi, > > Now i need to change GtkLabel color dinamically, so i thing that i > can't > use Css to do this.. I do this in Gtk2: > > gtk_widget_modify_fg(GTK_WIDGET(gtk_builder_get_object(builder,"label > ")),GTK_STATE_NORMAL, > ); > > How can i change the color in Gtk3? > > You can do it with CSS. But it has changed a bit for 3.20. You may compare this thread: https://mail.gnome.org/archives/gtk-list/2016-November/msg6.html Well, that was not for label widget, but for tooltip. But label widget should behave similar. And with similar code I once set foreground and background for button widgets -- I had that working for 3.18, but I have not yet fixed that for 3.20. (https://github.com/ngtk3/nim-gtk3/bl ob/master/test/colors.nim) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Homogeneous table
On Fri, 2017-03-10 at 10:32 +, Rúben Rodrigues wrote: > HI, > > Thanks for your reply. NExt i will change to gtk3, but i think that i > need to change many things.. It could be simple to make a homogeneous > table and hide images, unfortunately not.. I don't know exactly what you desire, but I have the feeling that it may be possible. Maybe you can use dummy images as place holders? Or maybe you can put your images first in some sort of (fixed size) container, and than put that container into the table? Or, when I remember the old Krause book correctly, I think there is some type of container available in GTK2 with allows absolute positioning. Maybe use that instead of a table? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 15:23 +, Emmanuele Bassi wrote: > Sorry, we haven't yet found the way to write a `gtk_do_what_i_mean()` > function. > > > But we have to tell them: We should not > > do that, it may be possible with CSS... So we have no Kids in GTK > for > > more than 10 years now, so so new coders, only a few tired seniors > > left. > > Again, I have no idea what kind of "kids in GTK" you are referring > to. > I see a lot of newcomers approaching GTK and GNOME development, > though. > > You may be hanging around in the wrong places. > > Ciao, > Emmanuele. Yes maybe. I am subscribbed to gtk-list, gtk-app-devel, gtk-source-view and gedit list. The last two are absolutely death. Someone told me to try IRC, so I joined it some months ago for a few hours, there was no traffic at all, so I disconnected... Other places? Years ago there was a web forum without much traffic, I am not sure if that still exists. Well I have never looked on Facebook or youtube for GTK people :-) People generally start in age about 12 with programming, and they like to do something that is fun. 5 lines CSS code to change a color is not that much fun unfortunately. Do you think they come back to GTK when they have threir PhD? At least, the few GTK coders I am aware of are all 30 or more years old, most are even older. Currently I am working on high level gobject introspection Nim bindigs, as you may remember... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 15:00 +, Rúben Rodrigues wrote: > Thanks for your help... Yes i don't understand why gtk doesn't aloow > us > to do some "basic" things.. Well, the GTK senior developers will say that such "color hacks" are ugly and do not fit theming well. That may be true. But the Problem is: When we try to teach Kids GTK programming, one of their first question is: How can I change that color. They expect a simple function and would have fun playing with it. But we have to tell them: We should not do that, it may be possible with CSS... So we have no Kids in GTK for more than 10 years now, so so new coders, only a few tired seniors left. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 15:52 +0100, Stefan Salewski wrote:
> On Wed, 2017-03-08 at 14:18 +, Rúben Rodrigues wrote:
> >
> > I asked to the Google before, but he don't give me nothing about
> > this
> > :-). PRELIGHT doesn't work too..
>
>
Well, the fix suggested by Owen Taylor in that old thread solved it for
me:
#include
gint main(gint argc,gchar *argv[])
{
GtkWidget *window;
GtkWidget* bar;
GdkColor color;
GtkStyle *style;
gtk_init (,);
window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
bar=gtk_progress_bar_new();
gdk_color_parse("red",);
gtk_widget_modify_bg(bar,GTK_STATE_NORMAL, );
gtk_widget_modify_bg(bar,GTK_STATE_PRELIGHT, );
gtk_widget_modify_bg(bar,GTK_STATE_ACTIVE, );
gtk_widget_modify_bg(bar,GTK_STATE_SELECTED, );
gtk_widget_modify_bg(bar,GTK_STATE_INSENSITIVE, );
gtk_widget_modify_fg(bar,GTK_STATE_NORMAL, );
gtk_widget_modify_fg(bar,GTK_STATE_PRELIGHT, );
gtk_widget_modify_fg(bar,GTK_STATE_ACTIVE, );
gtk_widget_modify_fg(bar,GTK_STATE_SELECTED, );
gtk_widget_modify_fg(bar,GTK_STATE_INSENSITIVE, );
style = gtk_style_new ();
gdk_color_parse ("red", >bg[GTK_STATE_PRELIGHT]);
gtk_widget_set_style (bar, style);
g_object_unref (style);
gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(bar),0.5);
gtk_container_add(GTK_CONTAINER(window),bar);
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: Gtk+ progress bar color
On Wed, 2017-03-08 at 14:18 +, Rúben Rodrigues wrote:
> I asked to the Google before, but he don't give me nothing about
> this
> :-). PRELIGHT doesn't work too..
Yes, you are right.
I just took this example:
https://www.spinics.net/lists/gtk/msg00686.html
//gcc -o simple t.c `pkg-config --libs --cflags gtk+-2.0`
#include
gint main(gint argc,gchar *argv[])
{
GtkWidget *window;
GtkWidget* bar;
GdkColor color;
gtk_init (,);
window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
bar=gtk_progress_bar_new();
gdk_color_parse("red",);
gtk_widget_modify_bg(bar,GTK_STATE_NORMAL, );
gtk_widget_modify_bg(bar,GTK_STATE_PRELIGHT, );
gtk_widget_modify_bg(bar,GTK_STATE_ACTIVE, );
gtk_widget_modify_bg(bar,GTK_STATE_SELECTED, );
gtk_widget_modify_bg(bar,GTK_STATE_INSENSITIVE, );
gtk_widget_modify_fg(bar,GTK_STATE_NORMAL, );
gtk_widget_modify_fg(bar,GTK_STATE_PRELIGHT, );
gtk_widget_modify_fg(bar,GTK_STATE_ACTIVE, );
gtk_widget_modify_fg(bar,GTK_STATE_SELECTED, );
gtk_widget_modify_fg(bar,GTK_STATE_INSENSITIVE, );
gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(bar),0.5);
gtk_container_add(GTK_CONTAINER(window),bar);
gtk_widget_show_all (window);
gtk_main();
return 0;
}
And on my box the bar is still blue!
GTK can be really hard and stubborn sometimes.
I do not have the GTK2 source codes on my box currently, so I can not
look at it currently. Maybe Mr Bassi or someone of the other few
remaining GTK insiders is still following this thread. At least now
your real goal is clear and we have tried it ourself :-)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 13:30 +, Rúben Rodrigues wrote: > Yes, doesn't work for me.. Because: > > gtk_widget_modify_bg(GTK_WIDGET(gtk_builder_get_object(builder,"Menu_ > Birds_ProgressBr")),GTK_STATE_NORMAL, > ); > > This changed background color, and this > > > gtk_widget_modify_fg(GTK_WIDGET(gtk_builder_get_object(builder,"Menu_ > Birds_ProgressBar")),GTK_STATE_NORMAL, ); > > Change text color. I want to change bar color.. Well, than we have to ask Mr Bassi or Google :-) Or look at the code... http://stackoverflow.com/questions/11172804/pygobject-gtk-entry-changing-progress-bar-color So please try gtk.STATE_PRELIGHT. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 12:29 +, Rúben Rodrigues wrote: > Hi, > > Thanks. Yes i want to change in gtk 2.x and change it in my app > only. > There's no way in proprieties? Do the ordinary GTK2 functions not work for your case? Like gtk_widget_modify_fg() and gtk_widget_modify_bg() https://developer.gnome.org/gtk2/stable/GtkWidget.html#gtk-widget-modify-fg http://stackoverflow.com/questions/99488/how-do-i-change-the-colors-of-an-arbitrary-widget-in-gtk ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Tue, 2017-03-07 at 15:43 +, Rúben Rodrigues wrote: > > > > Hi guys, > > > > How can i change progress bar color? > > > > Thanks > > > > For GTK 3.20 and above you can do it, using CSS. I did a similar fix for scrollbar width for my 27 inch 4 display. I think I wrote how I did it here some months ago. Basically you grap the CSS file, search for progressbar, copy that section to ~/.config/gtk-3.0/gtk.css and modify the color entry with a text editor. When you restart your application you should notice the new color. But maybe you want to use GTK2, Windows or Mac, or change it only for a specific app? And of course generally it may be a bad idea to modify single colors, because it may not really fit for arbitrary themes. And, not all widgets have plain colors, some have gradients and more. But I think for progressbar there is indeed a single color defined for GTK 3.20. And for personal use it should be OK. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gobject-introspection unmaintained?
On Mon, 2017-02-13 at 11:41 +, Emmanuele Bassi wrote: > > but the issue tracker is disabled. > > Because GNOME uses Bugzilla, not GitHub issues: https://bugzilla.gnom > e.org Ah yes -- found it. Yesterday I wondered why I get "\" as Dir_Separator on my Linux box, I thought I was doing something wrong. But it is already reported in bug696935 -- one of 283 open bugs. But in spite of that, gobject introspection seems to be a very useful tool. Rust people seems to use it too. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
gobject-introspection unmaintained?
Is gobject-introspection unmaintained? I found a github reposity at https://github.com/GNOME/gobject-introspection but the issue tracker is disabled. As you may know, I have done some work on a higher level GTK Nim wrapper recently. Starting with the API docs https://developer.gnome.org/gi/1.50/index.html was a bit hard at first, but then I made indeed some good progress. But of course the unconfirmed bugs like missing broken bitfield support may generate trouble? https://mail.gnome.org/archives/gtk-list/2017-February/msg00014.html https://mail.gnome.org/archives/python-hackers-list/2016-September/msg2.html Well, bitfields and the other strange points like g_enum_info_get_method() or g_base_info_iterate_attributes () may be not a serious problem. But I am asking myself if gobject-introspection may work for GTK 4 at all? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
GObject Introspection, g-field-info-get-size
https://developer.gnome.org/gi/1.50/gi-GIFieldInfo.html#g-field-info-get-size Is someone still familiar with GObject Introspection? I am investigating creating high level GObject Introspection based Nim bindings. Most seems to work well, some not: For example g-field-info-get-size() seems to give always zero. Is that intended? I may need that for introspecting structs with bit fields. Well, there are not many, but a few. Low level Nim bindings already exists, generated from header files with tool c2nim: https://github.com/ngtk3 But I have the feeling that for higher level bindings GObject Introspection may be fine -- when it works reliable. Another problem is g_enum_info_get_n_methods() and g_enum_info_get_method(). For some GTK3 enums n_methods seems to be greater than zero, but g_enum_info_get_method() gives garbage or crashes. But that is a minor problem, I may just ignore it. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: CSS to look more like Gtk+ 2
On Mon, 2016-12-19 at 14:01 +, Emmanuele Bassi wrote:https://ask.fedoraproject.org/en/question/84969/how-to-change- highlight-color-in-gnome-adwaita/ > The CSS theming classes and selectors were not API, they were > intentionally not documented, and thus fell under no stability > guarantee — until GTK+ 3.20, when they were finalized and deemed > expressive enough to allow you to write themes without necessarily > ending up writing C code to inject into applications. Indeed, for GTK 3.20 customization seems to work, and is not that difficult: I just found that link: https://ask.fedoraproject.org/en/question/84969/how-to-change-highlight-color-in-gnome-adwaita/ Question from Mar 2016, answer from December. But it really works, I was able to adjust slider width. (That tooltip example works also.) And, it is not even necessary to logout and login again to test changes, just restart the application. (Currently I am using a scaling of two for my whole display on a 28 inch 4k display, which is not bad, but most widgets are a bit large for my taste. Now I may consider going back to unscaled layout. Main problem with that was tiny slider size. But now that I can increase slider size that easy, and maybe a few other components too, I will try it again...) ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Where is the Gnome3 application menu for Cinnamon?
Thanks for your fast reply. So his complains seems to be justified, I will tell him and send him a link to your post. On Wed, 2016-12-21 at 01:13 +1100, Michael Gratton wrote: > On Wed, Dec 21, 2016 at 12:37 AM, Stefan Salewski <m...@ssalewski.de> > > wrote: > > > > Now someone tried my NEd editor with his cinnamon window manager. > > He > > told me that he has GTK 3.18 but can not find an application menu, > > so > > he can not open the preferences dialog. > > > We have something similar happen in Geary, the workaround (if it was > the same problem) was to adjust GtkSettings.gtk_decoration_layout at > startup to always include "menu": > https://bugzilla.gnome.org/show_bug.cgi?id=770617 > > I reported the issue for GTK+ but it was marked RESOLVED NOTGNOME: > https://bugzilla.gnome.org/show_bug.cgi?id=770619 > > HTH, > //Mike > ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Where is the Gnome3 application menu for Cinnamon?
My NEd Nim editor follows the scheme from https://developer.gnome.org/gtk3/stable/ch01s04.html#id-1.2.3.12.5 https://github.com/ngtk3/NEd So for Gnome shell it provides an application menu on top of screen which can open the preferences dialog. Very similar to gedit. Now someone tried my NEd editor with his cinnamon window manager. He told me that he has GTK 3.18 but can not find an application menu, so he can not open the preferences dialog. I have done some googling, but that was not really helpful. I strongly assume that there is some fallback for Cinnamon, but I can not tell him where. And I really can not install Cinnamon myself just to test it. Of course, when there really is no application menu for Cinnamon, I may provide a keyboard shortcut to open the preferences menu. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: CSS to look more like Gtk+ 2
On Tue, 2016-12-13 at 11:07 +0100, Stefan Salewski wrote: > Indeed, the current available scaling of factor 2 may be really fine > for a 34 inch 4k display and a eye to display distance of about one > metre. Sorry, that was nonsence. Indeed my feeling was and is, that a 34 inch monitor with default scaling (no factor two) and about 70 cm working distance may be fine. (Because widget size would be the same as for a 17 inch full HD screen.) ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: CSS to look more like Gtk+ 2
On Mon, 2016-12-12 at 18:48 -0800, Kyle Terrien wrote: > What's the favored way to "fake" a HiDPI monitor? Modify some pixel > density value in xorg.conf? Just increase the distance from your eyes to the display. What really matters is the viewing-angle. My feeling is, that for the popular 27 or 28 inch 4k desktop displays a scaling factor about 1.6 or 1.7 compared to the default schemes would be fine. This is for a distance eye to display about 70 cm. Indeed, the current available scaling of factor 2 may be really fine for a 34 inch 4k display and a eye to display distance of about one metre. But that large monitors are still expensive, have higher power consumption and need a really large table. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: CSS to look more like Gtk+ 2
On Sun, 2016-12-11 at 14:48 -0800, Kyle Terrien wrote: > And now, I'm starting another theme, It would also be great to have a HiDPI theme, or even better to have something like a scaleable theme. A theme where the elements like scrollbars can be scaled by running a script on it? I have currently a 27 inch 4k display. Default theme is really to tiny, so I have scaled the elements by factor two. That is not bad, but I would prefer most widgets scaled only by factor 1.5. I had done a google search for HiDPI themes, but did not really found something. I noticed that the default awaita theme css is generally not installed at all as textual CSS files, so I have not yet tried to customize one. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
