REMINDER: List moved to Discourse; archival in 1 week
Hi all; next week, on May 1st, this list will be archived[0]. This means no new subscriptions, and no new email. If you have questions about GTK, GLib, and the rest of the core GNOME development platform, you can use the Discourse[1] instance hosted on GNOME infrastructure; we have a Platform/Core category, and we can use appropriate tags that you can watch[2] and filter on. You can use existing single-sign on systems, like Google and Github, to authenticate yourself; if you have a GNOME LDAP account already, you're strongly encouraged to use that method of authentication. You can still use email to interact with Discourse, and a guide is available[3] to configure your account. If you have any questions or feedback on Discourse, please use the appropriate category[4]. Ciao, Emmanuele. [0]: https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg00024.html [1]: https://discourse.gnome.org [2]: https://discourse.gnome.org/t/tags-and-watching/94 [3]: https://discourse.gnome.org/t/interacting-with-discourse-via-email/46 [4]: https://discourse.gnome.org/c/site-feedback -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 drag and drop sample/demo
On Mon, 15 Apr 2019 at 12:45, Pankaj Bansal via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > I am working with OpenJDK JavaFX dev group and we are facing some problems > with drag and drop functionality with gtk3.20 or later. You can have a look > at the bug for more information > https://bugs.openjdk.java.net/browse/JDK-8211302. It will be great if > someone can point out any big change done with respect to drag and drop > from gtk3.20. > First of all, it's kind of rude to ask people to go to a random bug tracker and ask for a code review without stating what the issue is. Can you explain what issues are you experiencing? > I am looking for a sample/demo for drag and drop functionality using gtk3. > I can see that there is one demo at [1], but it is not compatible with gtk3 > as it is using gtk4 specific structs and functions. I am not able to find > any other working demo/sample working with gtk3. It would be great if > anyone can point to me to something useful. > The drag and drop code in GTK 3 hasn't really changed from the 2.x days, and has been substantially reworked for GTK 4. The old drag and drop tutorial may be of help: https://wiki.gnome.org/Newcomers/DragNDropTutorial Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: TreeView - set border on individual cells
On Sat, 6 Apr 2019 at 20:15, wrote: > The second cairo_t is used so that the rectangle can be lined up to the > cell. If I use the cairo_t in the "draw" callback then the rectangle > doesn't line up. > You're still using: 1. the wrong window to draw on 2. deprecated API 3. a slow rendering path In general, though drawing *on top* of widgets is not encouraged; you're either going to break things inside GTK, or your own code will break because GTK may change something in how widgets are drawn. If you want to change how a cell is rendered, you can subclass the cell renderer into your own class and override its own draw function; this way, you're guaranteed you'll be rendering at the right position. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: TreeView - set border on individual cells
On Sat, 6 Apr 2019 at 19:05, Eric Cashon via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:
> static gboolean draw_rectangle(GtkWidget *tree_view, cairo_t *cr, gpointer
> data)
> {
> GtkTreePath *path=gtk_tree_path_new_from_indices(row_g, -1);
>
> g_print("Draw Rectangle %i %i\n", row_g, column_g);
> GdkWindow *win=gtk_tree_view_get_bin_window(GTK_TREE_VIEW(tree_view));
> cairo_t *cr2=gdk_cairo_create(win);
>
Don't ever do this.
There's a reason why you're getting a deprecation warning: you're already
getting a Cairo context from the "draw" signal; use that to draw. There's
no reason whatsoever to create a new Cairo context for a GdkWindow in GTK3.
Ciao,
Emmanuele.
--
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: ANNOUNCE: Phasing out GTK mailing lists and move to Discord
On Thu, 21 Mar 2019 at 02:28, Matthew A. Postiff via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Is it easy in discourse to turn on email, either daily digests or > "live"? Is there an rss feed that I can subscribe to? A quick howto > would be great. > There is a link on how to use email with Discourse in the original email. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: ANNOUNCE: Phasing out GTK mailing lists and move to Discord
On Wed, 20 Mar 2019 at 23:59, David C. Rankin < drankina...@suddenlinkmail.com> wrote: > On 03/18/2019 12:02 PM, Emmanuele Bassi via gtk-app-devel-list wrote: > > Hi all; > > > > as announced in: > > > > > https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg0.html > > > > we have created a Discourse instance available at: > > > > https://discourse.gnome.org > What is the technological hold-up to doing both? Listserves are no cost > simple > implementations that should be able to mirror posts from discourse to the > existing list and vice-versa. This is an increasingly out of date position. Maintaining email servers and mailing lists is getting more and more complicated with every passing year. Sending thousands of emails to thousands of people every single day, and rewriting the envelope to make sure that the email comes from gnome.org, is becoming undistinguishable from spam. While we managed to carve out some exception using the established mechanisms, large ISPs are not really happy about all this stuff. > That would seem to be the way to go until you > have some assurance that discourse will preserve community involvement > instead > of just doing it on hope. > Splitting the community is not a great plan, so it's not going to happen. You can interact with Discourse via email, which is the main reason why we chose it as the platform to replace Mailman. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ANNOUNCE: Phasing out GTK mailing lists and move to Discord
Hi all; as announced in: https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg0.html we have created a Discourse instance available at: https://discourse.gnome.org After testing it for the past couple of weeks, we're very satisfied with how the platform behaves, so we are going to officially migrate all GTK-related discussion lists over to Discourse. This means the following mailing lists: - gtk-devel-list - gtk-app-devel-list - gtk-list Will be closed and archived on May 1st, 2019. The archives will remain public, but you won't be able to subscribe or send emails to the list. If you're subscribed to any of those lists you will receive a link to Discourse where you'll be able to create an account on that platform; you can also use other single sign-on systems, like Google or GitHub; and if you have an LDAP account on gnome.org, you're strongly encouraged to use that account. For further information on Discourse, please see the following topics: - https://discourse.gnome.org/t/interacting-with-discourse-via-email/46 - https://discourse.gnome.org/t/tags-and-watching/94 Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Discourse instance
Note: for those who prefer email, we've written down a handy guide on how to use email with Discourse: https://discourse.gnome.org/t/interacting-with-discourse-via-email/46 Ciao, Emmanuele. On Fri, 1 Mar 2019 at 15:50, Emmanuele Bassi wrote: > And, of course, I forgot the link: https://discourse.gnome.org > > Embarrassing. > > Ciao, > Emmanuele. > > On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi wrote: > >> Hi all; >> >> after the discussion[1] last month, and the feedback received (both on >> list and off), we decided to trial a Discourse instance on the GNOME >> infrastructure. >> >> The Platform/Core sub-category is meant to be used for all discussions >> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME >> stack. >> >> Email is still allowed for both posting and replying, though I strongly >> encourage people to give the web UI a try; it's really nice. >> >> Feedback is very much appreciated. >> >> Ciao, >> Emmanuele. >> >> [1]: >> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html >> >> -- >> https://www.bassi.io >> [@] ebassi [@gmail.com] >> > > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Discourse instance
And, of course, I forgot the link: https://discourse.gnome.org Embarrassing. Ciao, Emmanuele. On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi wrote: > Hi all; > > after the discussion[1] last month, and the feedback received (both on > list and off), we decided to trial a Discourse instance on the GNOME > infrastructure. > > The Platform/Core sub-category is meant to be used for all discussions > about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME > stack. > > Email is still allowed for both posting and replying, though I strongly > encourage people to give the web UI a try; it's really nice. > > Feedback is very much appreciated. > > Ciao, > Emmanuele. > > [1]: > https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Discourse instance
Hi all; after the discussion[1] last month, and the feedback received (both on list and off), we decided to trial a Discourse instance on the GNOME infrastructure. The Platform/Core sub-category is meant to be used for all discussions about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME stack. Email is still allowed for both posting and replying, though I strongly encourage people to give the web UI a try; it's really nice. Feedback is very much appreciated. Ciao, Emmanuele. [1]: https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Migrating away from GtkStock stuff
On Thu, 7 Feb 2019 at 13:30, Gabriele Greco wrote: > (test:77229): Gtk-WARNING **: 14:28:49.162: Could not find the icon > 'help-about'. The 'hicolor' theme > was not found either, perhaps you need to install it. > You can get a copy from: > http://icon-theme.freedesktop.org/releases > > (test:77229): Gtk-WARNING **: 14:28:49.162: Error loading theme icon > 'help-about' for stock: Icon 'help-about' not present in theme Adwaita > GTK uses `help-about` internally, because it doesn't use stock icons. You need an icon theme for the icons GTK uses, currently, though we're thinking of shipping a cut down version of Adwaita inside GTK for that reason: https://gitlab.gnome.org/GNOME/gtk/issues/1235 Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Migrating away from GtkStock stuff
On Thu, 7 Feb 2019 at 11:52, Gabriele Greco via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Hi guys, > > I'm in the process of migrating a big code base from GTK 2.x to GTK 3.x, > I've done most of the work, but I'm facing now some problems with GTK stock > stuff. > > I used stock stuff a lot to reduce the localizable strings needed in my > code and to reduce the number of images to ship. > > From what I've seen there are no more stock items in GTK 3 (3.24.2 at the > moment), since they have been deprecated in 3.10. > > That's not correct: GTK still ships the stock icons. You can find them in the tree as `gtk/icons///`. The icons themselves are built into the GTK shared library as GResources. The labels are still there, but you're strongly encouraged to ship your own strings, with your own mnemonics; GTK cannot know which mnemonics you or your translators use, so there will inevitably be conflicts, which will make your application look bad, or behave worse. > It's more a removal than a deprecation since my code compiles but the > program seems to fail to find at least the icons pointed by the stock item: > > (:75970): Gtk-WARNING **: 12:47:16.541: Error loading theme icon > 'document-new' for stock: Icon 'document-new' not present in theme Adwaita > (:75970): Gtk-WARNING **: 12:47:16.598: Error loading theme icon > 'document-open' for stock: Icon 'document-open' not present in theme > Adwaita > (:75970): Gtk-WARNING **: 12:47:16.599: Error loading theme icon > 'document-save' for stock: Icon 'document-save' not present in theme > Adwaita > (:75970): Gtk-WARNING **: 12:47:16.599: Error loading theme icon > 'edit-find' for stock: Icon 'edit-find' not present in theme Adwaita > > If you're using `edit-find` or `document-save` then you're using a named icon from the icon theme, not the stock identifier. For those, you'll have to ship an icon theme like Adwaita. There is a stack overflow post that suggests how to handle the migration > from a GtkStock item to a "named icon" or a "gtk localized label": > > > https://stackoverflow.com/questions/36805505/gtk-stock-is-deprecated-whats-the-alternative > > ... but what about toolbar or buttons that given the theme may have icons, > labels or both? > You are strongly encouraged to reduce the number of icons in your UI to begin with; icons need to be extremely recognisable if you want to reduce the mental load on users, and if you're showing both text and icons, users will use the text, not the icon, to know what ai UI element does—if they don't memorise the spatial location of the UI element, in which case they'll use spatial memory instead of icon/text memory: https://uxmyths.com/post/715009009/myth-icons-enhance-usability In any case, if you wish to move away from stock elements, the recommendation is to move to icon theme names (GTK deprecation notes will tell you what to use instead, if there is a replacement). If you don't want to ship a whole icon theme, because of disk/download size constraints, or build a list of icon assets you know you are using, and then you can either take the Adwaita icon theme and remove everything you don't use, or create the same file system layout as the icon theme but under your own application's data directory: https://wiki.gnome.org/DraftSpecs/ThemableAppSpecificIcons Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Moving from mailing lists to Discourse
More information on Discourse: - About: https://www.discourse.org/about - Features: https://www.discourse.org/features Discourse is a forum software that has multiple ways to access it: web, native apps, and email. It's not a mailing list software with a web frontend. The interesting (to me) parts are: - 2FA instead of Mailman's plaintext password - real moderation tools, that can scale with the community and encourage civility and code of conduct compliant behaviour - anti-spam measures - open source software (kind of a pre-requisite) - good UI for reading and replying to topics The Fedora (Silverblue) and Ubuntu communities already use Discourse, for instance; the SDL community also does. Ciao, Emmanuele. On Wed, 6 Feb 2019 at 12:46, Emmanuele Bassi wrote: > [Cross-posted to various relevant mailing lists; please, reply to > gtk-devel-list] > > As part of an attempt at making GTK more friendly to newcomers, I and > other core developers were thinking of moving the mailing lists from the > current mailman installation to Discourse: > > https://discourse.org/ > > Possibly still hosted on GNOME infrastructure, depending on the > requirements for our sysadmins. > > The GTK project would have various sub-topics, mostly around development > with and of GTK. Having a better archive search, a better moderation > system, and a decent web UI are the major selling points for switching to > Discourse. The fact that the project is also open source is neatly aligned > with our values. > > Are there any objections? Did somebody already try out Discourse and has > opinions about it that they want to share with the community? > > Ciao, > Emmanuele. > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Moving from mailing lists to Discourse
[Cross-posted to various relevant mailing lists; please, reply to gtk-devel-list] As part of an attempt at making GTK more friendly to newcomers, I and other core developers were thinking of moving the mailing lists from the current mailman installation to Discourse: https://discourse.org/ Possibly still hosted on GNOME infrastructure, depending on the requirements for our sysadmins. The GTK project would have various sub-topics, mostly around development with and of GTK. Having a better archive search, a better moderation system, and a decent web UI are the major selling points for switching to Discourse. The fact that the project is also open source is neatly aligned with our values. Are there any objections? Did somebody already try out Discourse and has opinions about it that they want to share with the community? Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Searching for text in PDF files is wrong
Hi; this list is for the development of applications with GTK; your question relates to Poppler, so you should ask on a Poppler-related mailing list or developers forum, e.g. https://lists.freedesktop.org/mailman/listinfo/poppler Ciao, Emmanuele. On Fri, 30 Nov 2018 at 20:56, Радомир Хаџић via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Hi. > > I use poppler_page_find_text() to find text in PDF files. This returns > GList of pointers to PopplerRectangles. Then I use > poppler_page_render_selection() to mark the found text. > > What is wrong is that PopplerRectangles returned by > poppler_page_find_text() are incompatible with those that > poppler_page_render_selection() requests, which is why the wrong text > is selected. > > I have found that to make those two compatible, I have to do the > following to PopplerRectangles returned by poppler_page_find_text(): > 1) SWAP(rectangle.x1, rectangle.x2); > 2) SWAP(rectangle.y1, rectangle.y2); > 3) rectangle.y1 = page_height - rectangle.y1; > 4) rectangle.y2 = page_height - rectangle.y2; > But this does not solve the problem because the marked text cycles > between right and wrong again while resizing the window. > > I have created a small program that illustrates the problem. Here it > is: https://pastebin.com/h3F56Yv7 (I've also sent an attachment but > last time you didn't get it so this paste is a fallback in case you > don't get it again.) > You ought to supply two arguments when running the program: the > absolute path to a PDF file and the text you want to search for, > respectively. Pay attention to the selected text with and without > lines 54-57. > > How can I make the found text to be marked properly? This "workaround" > does not work very well and it is an ugly solution anyway. > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Detect dark or light theme from an application
On Wed, 7 Nov 2018 at 00:48, Yuri Khan via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Hello everybody, > > I know in the GTK+3 theming engine a theme can define a light variant > and a dark variant. Is it possible, in an application, to know which > variant is currently used, and/or specify which widget in the > application uses which variant? > No. "Variants" are really only used by applications themselves, i.e. your application explicitly says that it prefers a dark variant of the current theme, if it's available. This is opt-in from the application perspective, though of course themes may not have a dark variant. User options do not change the theme variant: they change the theme; in other words, if a user decides to enable a dark theme globally, they will enable a dark theme, not the dark variant of the current theme. The only way to respect the GTK theme is to use GTK to render UI elements according to that theme—using the `gtk_render_*` API. Anything else is, by and large, impossible unless you literally parse the CSS with your own CSS parser, determine the colours of every UI element you care about, and then detect whether those colours are "light" or "dark". Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Segmentation fault when passing Poppler objects
On Tue, 6 Nov 2018 at 09:55, Радомир Хаџић via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:
> Hi. I get segmentation fault if I try to access a Poppler object whose
> pointer is passed through g_signal_connect. There is no such problem
> with normal pointers, though.
This:
> void draw_cb(GtkWidget *drawing_area, struct Colors *colors)
>
Is *not* the signature for a GtkWidget::draw signal callback.
The signature is:
gboolean (* draw) (GtkWidget *widget, cairo_t *context, gpointer
user_data);
0x5571faa9c6e0
> 0x5571fac68200
> current colors are:
> red 0.00
> green 0.00
> blue 0.00
> As we can see, colors in main and colors in draw_cb have different
> values, but this doesn't stop us from accessing the object (I wonder
> how this works, though it's not important in this case).
>
It "works" because you're getting passed a pointer to a memory area, and
you're trying to access it by 3 `sizeof(double)` offsets; the cairo_t
structure is large enough to accommodate those accesses without generating
a segmentation fault, but of course cairo_t does not contain 3 doubles at
the very beginning of its structure, so you're getting garbage that C
helpfully translates to a double representation. I also assume that you're
running on a 64 bit architecture, because if you tried the same of 32 bits
archs, you'd very much get a segmentation fault.
Of course, this will never work for a PopplerDocument instance, because
you're not trying to access the first `3 * sizeof(double)` bytes of it:
you're calling a Poppler function, which expects a PopplerDocument
instance, instead of a cairo_t one:
void doc_cb(GtkWidget *drawing_area, PopplerDocument *doc)
> {
> g_print("%p\n", doc);
> g_print("%d\n", poppler_document_get_n_pages(doc));
> }
>
>
Which is why you're getting a segmentation fault.
I strongly encourage you to read the GTK API reference:
https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-draw
In general, you should *always* read the documentation for each signal
you're using, to know the signature of the callback associated to the
signal. The signal machinery disables a lot of the type safety at compile
time in order to allow generic functions to be invoked without ad hoc
emitters.
Ciao,
Emmanuele.
--
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.0/3.0 Windows runtimes
Hi; On Tue, 23 Oct 2018 at 08:26, John Mills wrote: > Hello list > > If this question should be raised on another list, please let me know. > > I have been developing a C-language GTK+ 2.0 application for MS Windows 10 > using mingw > cross-compilation on Linux, and deploying it by installing the Windows > GTK+ 2.0 runtime > bundle on the Windows machine. > http://ftp.gnome.org/pub/gnome/binaries/win32/ > > The procedure was: on Linux development machine, unzip the gtk Windows > bundle in a directory > with the C source, set up a Makefile with the appropriate CFLAGS and > LDFLAGS, 'make mingw' > and deploy the EXE. This procedure suited my development style. > > Do I now need to port to GTK+ 3? > Considering that GTK 2.x is now in deep maintenance mode, you're strongly encouraged to migrate to GTK 3.24 — if and only if you're interested and have enough design and maintenance effort for the migration, and if you need functionality that is just never going to happen in the GTK 2.x branch. If you don't have any particular requirement, and you don't have enough bandwidth to migrate, then you can keep using GTK 2.24; it's not going to go away. Is MSYS2 now the best/only way to deploy the dependencies to Windows? > MSYS2 is the recommended way to *develop* an application using GTK 3.24 on Windows, natively. GTK developers are not going to ship binary builds for you, as we don't have the resources to do so—on any platform, in any case, not just on Windows. In order to ship GTK applications on Windows to your users you're strongly encouraged to take the builds you made and put them into an installer binary; your users do not need MSYS2. > Using the binaries available through MSYS2/pacman, can I still develop on > Linux and deploy > mingw executables to Windows? > You can still cross-compile on Linux for Windows; many Linux distributions have mingw packages to accomplish just that. The recommendation is still to package up your binary builds into an installer, and ship the installer to your users. > Can anyone point me to a guide for doing that? > There are various GTK applications that have build and release scripts for Windows; gedit and hexchat come to mind: - https://gitlab.gnome.org/GNOME/gedit/tree/master/win32 - https://github.com/hexchat/hexchat/tree/master/win32 For Linux/Windows cross-compilation there are distro-specific tutorials: - Fedora: https://fedoraproject.org/wiki/MinGW/Tutorial - Debian: https://wiki.debian.org/Mingw-W64 Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Wayland Window Positioning
You probably want to ask on gtk-devel-list and gnome-shell-list. Wayland interfaces need to be implemented by the compositor, and typically not piecemeal. That KDE interface seems to be a private interface shared between Plasma and kwin, like the gtk_shell interface is a private interface between GTK and GNOME Shell; typically what happens is that toolkit and compositor developers iterate over their requirements and then propose the addition of functionality to the xdg_shell shared interface. You could ask the gnome-shell developers to expose a similar functionality in the gtk_shell interface, and then GTK would be able to consume it; but that requires coordination between GNOME Shell and GTK releases. Ciao, Emmanuele. On Tue, 2 Oct 2018 at 11:13, Gerald Nunn via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > With respect to window positioning in Wayland, I was wondering if mutter > supports a Wayland extension to position windows similar to what > PlasmaShell does. Keep in mind I'm not very familiar with Wayland, however > looking at the Wayland protocol definition for PlasmaShell it looks like > they have this here: > > > https://github.com/KDE/kwayland/blob/master/src/client/protocols/plasma-shell.xml#L170 > > Looking at the similar file for gtk-shell I don't see anything similar: > > > https://github.com/GNOME/mutter/blob/master/src/wayland/protocol/gtk-shell.xml > > I have a lot of people asking me for Wayland support of quake mode in Tilix > where the terminal emulator sticks at the top or bottom of the screen. > Without being able to explicitly position the window this isn't possible. > Someone pointed me to Yuakake which seems to do it by integrating with the > PlasmaShell Wayland extension from what I can tell. > > Thanks, > > Gerald > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Any way to access treeview in GtkFileChooser?
Do you have an example of how you want to modify the style? Changing the style does not require access to the widget: it requires loading a CSS fragment in your application's startup code, and applying the appropriate selector to match the treeview inside the file chooser dialog. Ciao, Emmanuele. On Mon, 17 Sep 2018 at 16:15, Marco Ricci wrote: > I want to modify the column headers to be consistent with the style/theme > of the rest of the application I am working on. > > Thanks, > marco > > > On Mon, 9/17/18, Emmanuele Bassi wrote: > > Subject: Re: Any way to access treeview in GtkFileChooser? > To: marcoricci2...@yahoo.com > Cc: "gtk-app-devel-list list" > Date: Monday, September 17, 2018, 9:31 AM > > No, and it's never a good idea > to do so. > > Care to > tell use what are you trying to achieve? > > Ciao, > Emmanuele. > > > On Mon, 17 > Sep 2018 at 15:25, Marco Ricci via gtk-app-devel-list < > gtk-app-devel-list@gnome.org> > wrote: > I want to > get a handle to the GtkTreeView object that lists the files > in GtkFileChooser and customize it. Is there any way I can > access this object directly? > > ___ > > gtk-app-devel-list mailing list > > gtk-app-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > > > -- > > https://www.bassi.io > [@] ebassi [@gmail.com] > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Introspection data generation error in evince (autotools vs meson)
Just as a follow up to this for the archives, since it has been fixed in Evince[0]: - the issue is caused by a double declaration of `GType ev_document_model_get_type (void)`—one by the G_DECLARE_FINAL_TYPE at line 33, and one explicit at line 57. This confuses the g-ir-scanner parser, and would be nice to track it down a bit further - next time, you probably want to use gir-devel-list for this kind of issues, not gtk-app-devel-list Ciao, Emmanuele. [0]: https://gitlab.gnome.org/GNOME/evince/merge_requests/82 On Fri, 7 Sep 2018 at 07:35, Iñigo Martínez via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Hello, > > I have recently started porting evince to meson. The port is almost > complete but I have an issue with the generation of introspection data of > one of its libraries, `libevview3`, which I haven't been able to figure out > due to my limited introspection knowledge. > > The introspection build parameters are as follows in the autotools' > Makefile[0]: > > ``` > INTROSPECTION_COMPILER_ARGS = --includedir=$(top_builddir)/libdocument > > EvinceView-$(EV_API_VERSION).gir: libevview3.la > EvinceView_@EV_API_VERSION_U@_gir_FILES = \ > $(INST_H_SRC_FILES) \ > $(INST_H_BUILT_FILES) \ > $(filter %.c,$(libevview3_la_SOURCES)) > EvinceView_@EV_API_VERSION_U@_gir_INCLUDES = GLib-2.0 GObject-2.0 Gio-2.0 > Gdk-3.0 GdkPixbuf-2.0 Gtk-3.0 > EvinceView_@EV_API_VERSION_U@_gir_LIBS = libevview3.la > $(top_builddir)/libdocument/libevdocument3.la > EvinceView_@EV_API_VERSION_U@_gir_CFLAGS = \ > -I$(top_srcdir) \ > -I$(top_builddir) \ > -I$(top_srcdir)/libdocument \ > -I$(top_builddir)/libdocument \ > -DEVINCE_COMPILATION > EvinceView_@EV_API_VERSION_U@_gir_EXPORT_PACKAGES = > evince-view-$(EV_API_VERSION) > EvinceView_@EV_API_VERSION_U@_gir_SCANNERFLAGS = \ > --add-include-path=$(top_builddir)/libdocument \ > > > --include-uninstalled=$(top_builddir)/libdocument/EvinceDocument-$(EV_API_VERSION).gir > \ > --identifier-prefix=Ev \ > --symbol-prefix=ev > INTROSPECTION_GIRS = EvinceView-$(EV_API_VERSION).gir > > girdir = $(datadir)/gir-1.0 > gir_DATA = EvinceView-$(EV_API_VERSION).gir > > typelibsdir = $(libdir)/girepository-1.0 > typelibs_DATA = EvinceView-$(EV_API_VERSION).typelib > ``` > > These produces the following command lines: > > ``` > CPPFLAGS="" CFLAGS="-g -O2" LDFLAGS="-L/home/imartinez/jhbuild/install/lib > " CC="gcc" PKG_CONFIG="/usr/bin/pkg-config" GI_HOST_OS="" DLLTOOL="false" > /usr/bin/g-ir-scanner --namespace=EvinceView --nsversion=3.0 > --libtool="/bin/bash ../libtool" --include=GLib-2.0 --include=GObject-2.0 > --include=Gio-2.0 --include=Gdk-3.0 --include=GdkPixbuf-2.0 > --include=Gtk-3.0 --pkg-export=evince-view-3.0 --library=libevview3.la > --library=../libdocument/libevdocument3.la > --add-include-path=../libdocument > --include-uninstalled=../libdocument/EvinceDocument-3.0.gir > --identifier-prefix=Ev --symbol-prefix=ev --cflags-begin -I.. -I.. > -I../libdocument -I../libdocument -DEVINCE_COMPILATION --cflags-end > ev-document-model.h ev-jobs.h ev-job-scheduler.h ev-print-operation.h > ev-stock-icons.h ev-view.h ev-view-presentation.h ev-view-type-builtins.h > ev-annotation-window.c ev-document-model.c ev-form-field-accessible.c > ev-image-accessible.c ev-jobs.c ev-job-scheduler.c ev-link-accessible.c > ev-page-accessible.c ev-page-cache.c ev-pixbuf-cache.c ev-print-operation.c > ev-stock-icons.c ev-timeline.c ev-transition-animation.c ev-view.c > ev-view-accessible.c ev-view-cursor.c ev-view-presentation.c > ev-media-player.c libevview3.la --output EvinceView-3.0.gir > g-ir-scanner: link: /bin/bash ../libtool --mode=link --tag=CC gcc -o > > /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0 > -export-dynamic -g -O2 > > /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0.o > -L. libevview3.la ../libdocument/libevdocument3.la > -L/home/imartinez/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 > -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 > -L/home/imartinez/jhbuild/install/lib > libtool: link: gcc -o > > /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/.libs/EvinceView-3.0 > -g -O2 > > /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0.o > -Wl,--export-dynamic -pthread -Wl,--export-dynamic -L. > ./.libs/libevview3.so ../libdocument/.libs/libevdocument3.so > -L/home/imartinez/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 > -lglib-2.0 -pthread -Wl,-rpath -Wl,/tmp/evince/lib > g-ir-scanner: EvinceView: warning: 2 warnings suppressed (use --warn-all to > see them) > ``` > > This command creates the `EvinceView-3.0.gir` file properly. I tried to > replicate this on meson by using the same parameters[1]: > > ``` > incs = [ > 'Gdk-3.0', > 'GdkPixbuf-2.0', > 'Gio-2.0', > 'GLib-2.0', > 'GObject-2.0', > 'Gtk-3.0', >
Re: "draw" icon with string
On Tue, 4 Sep 2018 at 00:09, c.buhtz--- via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Dear Emmanuele, > > you describe how to set a drag icon. I know how to do this. > https://stackoverflow.com/q/51975256/4865723 > > But the question is how do I create my icon? > That's what I wrote in my email: > If you want to override that, you should call > gtk_drag_set_icon_surface(), using a Cairo surface you created: > > https://developer.gnome.org/gtk3/stable/gtk3-Drag-and-Drop.html#gtk-drag-set-icon-surface > > The GtkTreeView uses the default handler of the GtkWidget::drag-begin > signal to set the drag icon; you want your own handler to be called > after that, so you can override the drag icon with your own. Icons are Cairo surfaces; this means you need to create a Cairo surface and render on it using the Cairo API. > e.g. TreeView create it's own one, too. It is based on the row content. > I can I do the same? e.g. I only want the content of the second > column/cell and not the complete row? > You can get the contents of the model and render them as you wish, using the gtk_render_* API. Ciao, Emmanuele. On 2018-09-02 02:33 Emmanuele Bassi > wrote: > > On Sat, 1 Sep 2018 at 22:20, c.buhtz--- via gtk-app-devel-list < > > gtk-app-devel-list@gnome.org> wrote: > > > > > I want to use my own drag-icon in a Gtk.TreeView where this is set > > > as an instance of GdkPixbuf.Pixbuf. > > > > > > I can I create/draw a pixbuf and create Text, background and border > > > color in it? > > > > > > > Typically, GtkTreeView will call gtk_tree_view_create_row_drag_icon() > > for the default drag surface — a box with the contents of the row. > > > > > https://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-create-row-drag-icon > > > > If you want to override that, you should call > > gtk_drag_set_icon_surface(), using a Cairo surface you created: > > > > > https://developer.gnome.org/gtk3/stable/gtk3-Drag-and-Drop.html#gtk-drag-set-icon-surface > > > > The GtkTreeView uses the default handler of the GtkWidget::drag-begin > > signal to set the drag icon; you want your own handler to be called > > after that, so you can override the drag icon with your own. To do > > that, you can: > > > > - call gtk_tree_view_unset_model_drag_source() or > > gtk_tree_view_unset_model_drag_dest() and implement your own drag and > > drop handling > > - call g_signal_stop_emission_by_name() in your drag-begin callback > > to stop the signal emission chain, and prevent the default handler > > from running > > - use g_signal_connect_after() to connect your callback, and have > > your handler run after the default one > > - subclass GtkTreeView and override the drag_begin() virtual function > > without chaining up, to implement your own handler > > > > Ciao, > > Emmanuele. > > > > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: "draw" icon with string
On Sun, 2 Sep 2018 at 02:02, Chris Moller wrote: > You probably can't do that--GTK has gotten just about impossible to > customise--but if you can do it at all, you'll probably have to use CSS. > Please, avoid this kind of unhelpful reply in the future. Ciao, Emmanuele. On 01/09/18 17:20, c.buhtz--- via gtk-app-devel-list wrote: > > I want to use my own drag-icon in a Gtk.TreeView where this is set as > > an instance of GdkPixbuf.Pixbuf. > > > > I can I create/draw a pixbuf and create Text, background and border > > color in it? > > ___ > > gtk-app-devel-list mailing list > > gtk-app-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > > > > > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: "draw" icon with string
On Sat, 1 Sep 2018 at 22:20, c.buhtz--- via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > I want to use my own drag-icon in a Gtk.TreeView where this is set as > an instance of GdkPixbuf.Pixbuf. > > I can I create/draw a pixbuf and create Text, background and border > color in it? > Typically, GtkTreeView will call gtk_tree_view_create_row_drag_icon() for the default drag surface — a box with the contents of the row. https://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-create-row-drag-icon If you want to override that, you should call gtk_drag_set_icon_surface(), using a Cairo surface you created: https://developer.gnome.org/gtk3/stable/gtk3-Drag-and-Drop.html#gtk-drag-set-icon-surface The GtkTreeView uses the default handler of the GtkWidget::drag-begin signal to set the drag icon; you want your own handler to be called after that, so you can override the drag icon with your own. To do that, you can: - call gtk_tree_view_unset_model_drag_source() or gtk_tree_view_unset_model_drag_dest() and implement your own drag and drop handling - call g_signal_stop_emission_by_name() in your drag-begin callback to stop the signal emission chain, and prevent the default handler from running - use g_signal_connect_after() to connect your callback, and have your handler run after the default one - subclass GtkTreeView and override the drag_begin() virtual function without chaining up, to implement your own handler Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: return value from expose event / draw signal of GtkDrawingArea
Hi; On Tue, 14 Aug 2018 at 17:30, Luca Bacci via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Hi, does anyone know what meaning has the return value from expose event > handler (for gtk2) and draw signal (for gtk3) of GtkDrawingArea? > > When one should return TRUE, and when FALSE? > > I can't find any information in the reference manual > The "expose-event" signal in GTK+ 2.x comes from GtkWidget: https://developer.gnome.org/gtk2/stable/GtkWidget.html#GtkWidget-expose-event The "draw" signal in GTK+ 3.x comes from GtkWidget: https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-draw They have similar semantics as other signals in GTK+, like the input-related ones: returning TRUE means "I handled this signal emission, so do not propagate it further to other signal handlers"; returning FALSE means "I did not handle this signal emission, so propagate it further to other signal handlers". What "handling" means it depends on what you want to achieve. When using GTK+ 3.x, you're strongly encouraged to use the symbolic constants "GDK_EVENT_PROPAGATE" and "GDK_EVENT_STOP", instead, as they make the code easier to read. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: PyGObject: FileChooserDialog and transient parent
Hi; On Sun, 12 Aug 2018 at 12:33, c.buhtz--- via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Below you see a minimal working example using Gtk.FileChooserNative as > a file-open dialog. While running with Python 3.6.6 I recieve > this warning message > > "GtkDialog mapped without a transient parent. This is discouraged." > > I understand the logic behind it but can not find a solution BECAUSE > the docu is IMO inusfficient. Please see > > < > https://lazka.github.io/pgi-docs/#Gtk-3.0/classes/FileChooserDialog.html#Gtk.FileChooserDialog > > > > This docu is about PyGObject which is Python, isn't it!? But there is C > code in the example. Also with my C experience this doesn't help. > The documentation for Python/GObject bindings is generated from the introspection data, which is in turn generated from comments and annotations inside the C code. The C code comes with C examples, because writing examples in Python, Perl, JavaScript, whatever inside the C documentation would be odd, and could not be validated in any way by the C developers. Yes, it would be nice if we had a translation layer for introspected languages using the documentation inside the generated data; it's been a request for a long time, but nobody has shown up to do the work. What IMO is missing in that documentation and what would help me to > understand and solve the problem by myself without contacting the list > or issue tracker is > - Description of the Constructor or new() > - all possible parameters accepted by this constructor (I have no idea >where and how to put a parent to it) > The properties are inherited from the GtkFileChooserDialog class, so you'll have to look at the hierarchy of the type, namely: - GtkWidget - GtkWindow - GtkDialog The transient parent is provided by the transient-for property on GtkWindow: https://developer.gnome.org/gtk3/stable/GtkWindow.html#GtkWindow--transient-for or: http://lazka.github.io/pgi-docs/#Gtk-3.0/classes/Window.html#Gtk.Window.props.transient_for In any case, it would be good to file this as an issue against pygobject: https://gitlab.gnome.org/GNOME/pygobject/issues/new Documentation doesn't magically improve by itself, and issues are how projects can work on improving it, as long as they provide actionable items and goals. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_screen_get_width/height
Use the GdkMonitor API; GdkScreen is an X11-ism, and a single screen can cover multiple outputs. https://developer.gnome.org/gdk3/stable/GdkMonitor.html Ciao, Emmanuele. On Thu, 2 Aug 2018 at 14:58, Wojciech Puchar wrote: > > > On 2018.08.02 15:55, Wojciech Puchar wrote: > > how to get width/height of smallest available display - in case of > > multiple monitors are attached? > > > or to be more exact - how to enumerate screens. > > all i need is to get resolution of smallest attached monitor. > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: question about gtk_dialog (gtk2)
You haven't specified which windowing system you're using.
If it's X11, then the position of a window is always the remit of the
window manager; the position set is a hint, which is taken into account by
the window manager itself, alongside the "this is a dialog" hint that
GtkDialog sets.
There's no toolkit-available way to say "set this window to be at the
center of the screen", unless you create a GTK_WINDOW_POPUP and thus ask
the window manager to *not* manage your window.
Ciao,
Emmanuele.
On Fri, 15 Jun 2018 at 12:44, Wojciech Puchar
wrote:
> how to make dialogs appear on center of screen not on left corner. tried
> multiple things no results. For normal windows gtk_window_set_position
> works
>
> for dialog it doesn't
>
> below is example routine to ask a yes/no question from my program.
>
>
> i've tried
> gtk_window_set_position(GTK_WINDOW(dialog),GTK_WIN_POS_CENTER_ALWAYS);
>
> but it doesn't work
>
>
> nt pytanie(const char *txt) {
> GtkWidget *dialog,*lab;
> int odpowiedz;
>
> dialog=gtk_dialog_new_with_buttons(TEXT_QUESTION,NULL,GTK_DIALOG_DESTROY_WITH_PARENT,
> TEXT_TAK,GTK_RESPONSE_ACCEPT,TEXT_NIE,GTK_RESPONSE_NONE,NULL);
> lab=new_label(txt);
> gtk_container_add (GTK_CONTAINER (gtk_dialog_get_content_area
> (GTK_DIALOG (dialog))), lab);
> odpowiedz=gtk_dialog_run(GTK_DIALOG(dialog));
> gtk_widget_destroy(dialog);
> return (odpowiedz==GTK_RESPONSE_ACCEPT);
> }
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
--
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
