DhCompletion, a GCompletion replacement

Hi, Just a small announce, I've implemented recently a replacement for GCompletion in Devhelp. GCompletion is deprecated, but for some applications it's still useful to have a string completion utility. https://git.gnome.org/browse/devhelp/tree/src/dh-completion.h

Re: First deprecate APIs and then remove them in the next major version

On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote: > I know this may sound harsh, but: If you want things to work differently, > send patches. > Patches to the migration guide are welcome too. > > The bulk of the work done on GTK4 so far has been done by 3 or 4 people, > only one of

Re: First deprecate APIs and then remove them in the next major version

On Thu, Dec 14, 2017 at 08:34:51PM +, Emmanuele Bassi wrote: > On 14 December 2017 at 18:42, Sébastien Wilmet <swil...@gnome.org> wrote: > > A recent example: > > https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39 > >

Re: First deprecate APIs and then remove them in the next major version

On Thu, Dec 14, 2017 at 08:02:56PM +0100, Bastien Nocera wrote: > On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote: > > > > > With "soft API breaks" (i.e. just removing an API that was deprecated > > in > > a previous major version), I think th

Re: First deprecate APIs and then remove them in the next major version

On Wed, Dec 13, 2017 at 03:08:46PM -0800, Christian Hergert wrote: > On 12/13/2017 04:05 AM, Sébastien Wilmet wrote: > > Can I remind you that most of the biggest GTK+ apps are still using > > GTK+ 2? MonoDevelop, GIMP, Ardour, … > > MonoDevelop is still Gtk2 because N

Re: First deprecate APIs and then remove them in the next major version

On Wed, Dec 13, 2017 at 04:55:41PM +, Emmanuele Bassi wrote: > The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand. No, that's not true. A recent example: https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39 "gtk: Remove GtkClipboard"

First deprecate APIs and then remove them in the next major version

Hi, I'm a bit worried about how GTK+ 4 is developed. It seems that there will be a lot of API breaks that will require to adapt the code at once. Ideally, a new major version of a library should only remove deprecated APIs. It's how a library should be developed, in case the developers want to

Re: g_object_ref() now propagates types

On Fri, Dec 08, 2017 at 11:26:31AM +, Philip Withnall wrote: > Note that the new behaviour requires GCC, and is only enabled if you > have defined GLIB_VERSION_MAX_ALLOWED >= GLIB_VERSION_2_56. If GLIB_VERSION_MAX_ALLOWED is not defined, does it take by default the value of the last GLib

Re: Gtk+4.x and broadway ( and other remote options )

On Thu, Dec 07, 2017 at 08:57:46AM +0100, Alexander Larsson wrote: > Maybe someone else is interested in consulting work on it though? There is a list of consultancy partners here: https://www.gtk.org/support.php ___ gtk-devel-list mailing list

Re: GApplication process uniqueness, saving config files and multi-seat support

On Mon, Sep 11, 2017 at 02:25:43PM +0200, Bastien Nocera wrote: > As a general rule, we don't support being logged in to the same account > on 2 different seats, whether they share the same physical machine, or > just the backing storage. > > On physical machines, this is enforced by gdm, and a

Re: Catalog of GObject-specific design patterns?

ly common to use hashmaps in its implementation. Now I better understand, thanks for the explanations. -- Sébastien > On Sun, Aug 13, 2017 at 12:33 PM, Sébastien Wilmet <swil...@gnome.org> wrote: > > On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote: > >> I use

Re: Catalog of GObject-specific design patterns?

On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote: > I use some patterns like: > > http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_recall_factory.h > http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/plugin/ags_lv2_manager.h > ... > > Or having an

Re: Building glib-genmarshal (while building glib)

On Sat, Aug 12, 2017 at 01:54:29PM +0100, John Emmas wrote: > What's happened to 'glib-genmarshal.c'? It seems to have been removed from > git master - although (AFAICT) it doesn't get auto-generated. A new file > does get generated (gobject/glib-genmarshal) but i can't see how that gets > used

Re: Catalog of GObject-specific design patterns?

On Fri, Aug 11, 2017 at 09:16:32AM +0700, Arnaud wrote: > As for using the `g_object_set_data()` like you do, it's something I > always tried to stay away from, because it seems to me that everything > becomes possible with that, and there's probably plenty of mistakes to > be made ;) On the other

Catalog of GObject-specific design patterns?

Hi, I've documented my first GObject design pattern: https://blogs.gnome.org/swilmet/2017/08/09/gobject-design-pattern-attached-class-extension/ Question to the old-timers: do you know any other GObject-specific design pattern? Not applying the classic design patterns with GObject, I'm talking

Amtk - Actions, Menus and Toolbars Kit for GTK+

Hi, You're maybe not aware of the problem, but the GtkUIManager deprecation is really painful for developers who want to keep a traditional UI for their application. See all the work that I've done recently in the Amtk library (3000 lines of code, and some features are still missing):

Re: GTK+ 4: knowing the action/event at the origin of a text insertion/deletion?

On Sat, Jul 08, 2017 at 10:08:56AM +0200, Timm Bäder wrote: > On 07.07, Sébastien Wilmet wrote: > > But heuristics are not ideal of course. Will the input handling rework > > in GTK+ 4 support that use-case? > > As far as I know, the input rework so far only touches po

GTK+ 4: knowing the action/event at the origin of a text insertion/deletion?

Hi, With the plans for GTK+ 4, I wonder if it'll solve the following use-case. Knowing where does a text insertion/deletion come from. In GtkTextView and GtkEntry. Is it a key press? Is it a cut/paste/…? Is it done programmatically? Etc. Because currently with GTK+ 3 there are heuristics in

Re: Licensing

On Sun, May 28, 2017 at 05:38:26PM +0100, John Emmas via gtk-devel-list wrote: > On 28/05/2017 14:41, Sébastien Wilmet wrote: > > On Wed, Apr 19, 2017 at 09:02:21AM +0100, John Emmas via gtk-devel-list > > wrote: > > > the following 11 header files stipulate GPL:- >

Re: Licensing

On Wed, Apr 19, 2017 at 09:02:21AM +0100, John Emmas via gtk-devel-list wrote: > Hi guys - whilst checking something else this morning I came across an > anomaly in the licensing mechanism for glib / gtk+ etc. > > The vast majority of the header files state that it's LGPL. But > occasionally

Re: What does "(skip)" mean ???

Hi, Replying only to the mail subject: It's a GObject Introspection annotation !!! https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org

Re: gio enhancement.

Hi, On Thu, Apr 13, 2017 at 10:14:08AM +0200, Bruggemann Eddie wrote: > Or For multimedia files (Video, Music, Image) providing a way to access the > meta-data: > > in a type like this: > > GMediaFileInfo > > --- > > Else because Gtk has a library for the font (pango) for drawing (cairo) for

Re: Migrating from GTK+ 2.x to GTK+ 3

Hi, On Tue, Feb 14, 2017 at 12:25:32PM +, Rúben Rodrigues wrote: > i'm new on Linux and gtk+. I'm trying to migrate an application make > with gtk+2.0, and i'm following this tutorial > https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html There is also this guide that may be

Re: Moving to glade and GtkInspector

Hi, On Mon, Apr 03, 2017 at 01:29:01AM -0400, Martin Owens wrote: > I'm brining this up in devel mailing list because it might not be > possible to do well enough, but I'm interested in raising the question > of moving projects from widget code to glade ui files. > > I work on Inkscape. The next

Re: Versioning and long term stability promise in GTK+

On Mon, Jan 30, 2017 at 11:17:55AM +, Emmanuele Bassi wrote: > On 29 January 2017 at 10:00, Sébastien Wilmet <swil...@gnome.org> wrote: > > On Sat, Sep 03, 2016 at 02:09:04PM +0100, Emmanuele Bassi wrote: > >> https://blog.gtk.org/2016/09/01/versioning-and-long-term-

Re: Versioning and long term stability promise in GTK+

On Sat, Sep 03, 2016 at 02:09:04PM +0100, Emmanuele Bassi wrote: > https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ In the above announcement, you've written: More details about these plans, including specifics for library developers and

Re: gtk_text_iter_forward_search() comparison

On Sat, Jan 28, 2017 at 07:16:04PM -0500, Eric Cashon via gtk-devel-list wrote: > I have been working on a little search experimentation. Gave writing a > case in-sensitive gtk_text_iter_forward_search() a try. The code is > shorter than what is in gtktextiter.c and it works a little faster. If >

Re: Contributing

On Tue, Jan 03, 2017 at 09:19:00PM +0200, Panagiotis Follas wrote: > Have you already written an application in GTK+? No. Yes I would like. > Have you already written a library based on GLib/GTK+? No. But I would like. > > I have half read the book "Foundations of GTK+ Development" and I tried to

Re: Contributing

On Tue, Jan 03, 2017 at 08:19:49PM +0200, Panagiotis Follas wrote: > I am developer, and I would like to contribute to gtk development. But > first I would like some guidance. > I can code on windows 7 platform. Like where to start and how. See: http://ometer.com/hacking.html Have you already

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

On Thu, Dec 29, 2016 at 11:55:35PM +0100, Stefan Sauer wrote: > Sorry for reviving the thread. What if upstream lib ship a suppression > file and add a pkg-config variable pointing to it? Then apps can use > $PKG_CONFIG --variable=valgrind_suppressions gtk+-3.0 > to collect those and e.g. export

Re: Gtk+4.x and broadway ( and other remote options )

On Wed, Dec 07, 2016 at 02:18:24PM +1100, Daniel Kasak wrote: > Another option, if the task is too large or difficult for me, is to > either offer a bounty here, or to post a project on something like > freelancer. I also realise that work done via freelancer would > possibly be of questionable

Re: [RFC] Renaming the GtkSourceView namespace from GtkSource to Gsv

On 10/20/2016 08:05 AM, Georges Basile Stavracas Neto wrote: > My personal opinion is that it's a good move, even though it'll create > some pain. Since the API itself won't change behavior-wise, adapting the > code to the new change will be simple enough (a Search and Replace > throughout the

[RFC] Renaming the GtkSourceView namespace from GtkSource to Gsv

Hi, For GtkSourceView 3.90, there is a plan to rename the namespace from GtkSource to Gsv: https://bugzilla.gnome.org/show_bug.cgi?id=755752 Because the current namespace (GtkSource, or gtk_source in lowercase) conflicts with the GTK+ one. But I have never heard complaints from GTK+ developers.

Re: Gtk+4.0

On Sat, Sep 03, 2016 at 02:19:11PM +0100, Emmanuele Bassi wrote: > On 3 September 2016 at 10:27, Sébastien Wilmet <swil...@gnome.org> wrote: > > > The versioning looks much better. Small detail, during the next > > development cycle, the alpha/beta/rc versions will be 3.8

Re: Gtk+4.0

To people who might have missed it: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ Some comments: “While the GTK+ team reserves the right to change API during development series, this does not mean that the whole GTK+ API will constantly break each release;

Re: Gtk+4.0

On Wed, Aug 17, 2016 at 03:06:43PM +, Philipp A. wrote: > Peter Weber schrieb am Mo., 15. Aug. 2016 um > 14:20 Uhr: > > > Gtk is the GNOME-Toolkit and it's fine, if XFCE or Cinnamon put work > > inside Gtk it > > could also named the GNU-Toolkit. > > > > is this a

Re: Gtk+4.0

On Mon, Aug 15, 2016 at 02:20:25PM +0200, Peter Weber wrote: > I think breaking the API/ABI because of required changes, is right, > breaking API/ABI because a fixed number of months has passed doesn't make > much sense. >From time to time, it is nice to get rid of deprecated APIs, to have less

Re: Gtk+4.0

On Sun, Aug 14, 2016 at 07:17:34PM +0100, Chris Vine wrote: > On Sun, 14 Aug 2016 13:40:55 +0200 > Sébastien Wilmet <swil...@gnome.org> wrote: > > When GTK+ breaks the API, it doesn't mean that a higher-level library > > needs to break API too. For example, GtkTextView ha

Re: Gtk+4.0

On Fri, Aug 12, 2016 at 04:19:30AM +, philip.chime...@gmail.com wrote: > 4. Maintainers of libraries that depend on GTK (such as GtkSourceView, VTE, > WebKitGTK) are concerned about having to maintain essentially a separate > library for each unstable release. Actually, I do not fully

Re: Gtk+4.0

On Sun, Aug 14, 2016 at 09:03:23AM -0400, Morten Welinder wrote: > > When GTK+ breaks the API, it doesn't mean that a higher-level library > > needs to break API too. > > That depends. > > You are right that a lot of API changes can be hidden. > > But if the higher-level library has an API

Re: Gtk+4.0

On Sun, Aug 14, 2016 at 01:05:08PM +, Philipp A. wrote: > I tried just to read and not ask anything but no amount of reading has > resulted in any enlightenment, so: > > Why not do what almost everyone does and have 4.X mean “stable” while > anything with alpha/beta/pre/rc means unstable? >

Re: Gtk+4.0

On Fri, Aug 12, 2016 at 04:19:30AM +, philip.chime...@gmail.com wrote: > 4. Maintainers of libraries that depend on GTK (such as GtkSourceView, VTE, > WebKitGTK) are concerned about having to maintain essentially a separate > library for each unstable release. When GTK+ breaks the API, it

Re: Alternative to swallow GtkContainer into GtkWidget

On Tue, Aug 02, 2016 at 04:48:03PM -0700, Jasper St. Pierre wrote: > What you miss is that GtkWidget already has container-like behaviors with > gtk_widget_set_parent. In fact, the whole API has been awkward. GtkWidgets > themselves can have children. GtkContainer is a "convention" interface for >

Re: Alternative to swallow GtkContainer into GtkWidget

On Tue, Aug 02, 2016 at 07:57:04PM +0200, Sébastien Wilmet wrote: > I see at: > https://wiki.gnome.org/Hackfests/GTK2016/Day1 > > That there is maybe a plan to merge GtkContainer into GtkWidget. More precisely, "Next step after that would be to make gadgets real wid

Alternative to swallow GtkContainer into GtkWidget

Hi, I see at: https://wiki.gnome.org/Hackfests/GTK2016/Day1 That there is maybe a plan to merge GtkContainer into GtkWidget. >From a software engineering point of view, this looks like a bit scary to me. $ wc -l gtkwidget.c 17510 gtkwidget.c $ wc -l gtkcontainer.c 3880 gtkcontainer.c

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

On Tue, Aug 02, 2016 at 01:47:41PM +0100, Philip Withnall wrote: > On Mon, 2016-08-01 at 20:10 +0200, Sébastien Wilmet wrote: > > So, is there an up-to-date Valgrind suppression file somewhere? Or is > > GNOME.supp the most up-to-date? > > The one I’ve been using is here: &g

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

On Wed, Jun 22, 2016 at 05:19:19PM +0100, Simon McVittie wrote: > If there is a compelling advantage to splitting up libraries, of course, > by all means do so. I have an example: gspell: https://wiki.gnome.org/Projects/gspell The non-GUI parts could be implemented in GIO, with an extension

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

On Wed, Jun 22, 2016 at 08:47:02PM +0200, Bastien Nocera wrote: > Link it against gtk-3.0-wayland instead of both the x11 and wayland > versions, and try again? My nautilus links against 25 X libraries, both > the old-school versions and the xcb async versions. And to wayland libs > as well as

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

On Wed, Jun 22, 2016 at 05:19:19PM +0100, Simon McVittie wrote: > On 22/06/16 13:14, Sébastien Wilmet wrote: > > Time for another Project Ridley? > > Maybe; or maybe the benefit of those 30 extra libraries outweighs their > cost (CPUs are faster now than in the GNOME 2 days

Number of dynamically linked libraries (Was: Re: Gtk+4.0)

On Tue, Jun 21, 2016 at 05:07:46PM +0100, Simon McVittie wrote: > > 2. Add experimental features through external libraries (libsexy and so > > on?) > and linking a large number of tiny libraries has a measurable startup > cost for applications.

Re: Developing a new text editor widget?

On Wed, Jun 15, 2016 at 08:13:54AM -0400, Simon McVittie wrote: > Monospace environments like terminals traditionally display æ, œ, … as > a single character-cell: it isn't typographically correct, but neither > is having m the same width as i, and we tolerate that in monospace. > > The one use

Re: Developing a new text editor widget?

On Sun, Jun 05, 2016 at 12:33:20PM -0700, Christian Hergert wrote: > You wouldn't want to mmap() the whole file, because that would still > limit how large of a file you can open on 32-bit systems. You would want > mapping windows with a page replacement strategy. Once you get this far, > mmap()

Re: Developing a new text editor widget?

On Sun, Jun 05, 2016 at 03:15:30PM -0400, Rena wrote: > As an application developer, my main gripes with GtkTextView have been: > > 1. The view/buffer model. I expected that the view just asks the buffer for > text, and I could supply a custom buffer object that generates text on the > fly. In

Developing a new text editor widget?

Hi, I'm not going to the GTK+ hackfest, but there is one subject listed on the wiki page that I want to talk about: textview/sourceview replacements. Christian talked a bit about it here: https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00037.html Which is inspired by this paper:

Re: gtk/quartz ... a tale of nested incompatible event loops

On Mon, May 23, 2016 at 01:29:44PM -0400, Paul Davis wrote: > I'm emailing it > just in case anybody else decides to wade into a complete overhaul of the > design of the glib event loop on Quartz. Looks somewhat obscure and low-level. I think on bugzilla it would have more chances to be read

Re: g_error_free() warning on null pointer

On Mon, Aug 31, 2015 at 11:03:40PM -0400, Michael McConville wrote: > 1) print an annoying warning Not always, as Simon explained already, the g_return_if_fail()/... functions can be disabled, in which case the program continues its execution and will usually crash. See the --enable-debug

Re: Custom TextBuffer

Hi, On Sun, Aug 30, 2015 at 12:22:36AM -0400, Rena wrote: I want to use a TextView to display information as marked-up text. This information is generated on the fly and would span millions of lines that the user can page through. It seems like the idea would just be to subclass GtkTextBuffer

Re: g_error_free() warning on null pointer

On Sat, Aug 15, 2015 at 01:52:02PM -0700, Jasper St. Pierre wrote: Lots of things in GLib fail when passed a NULL pointer, like g_object_unref. The idea is that passing a NULL pointer is probably a sign of a bug somewhere, so you shouldn't do it. No, accepting a NULL pointer for free

Re: g_error_free() warning on null pointer

On Sun, Aug 16, 2015 at 10:49:56AM +0100, Emmanuele Bassi wrote: Consistency is important for a library. It's much simpler to remember all free/unref functions accept NULL instead of free/g_free accept NULL, g_object_unref not, g_clear_object yes, etc etc. unref() is not a free function,

Re: g_error_free() warning on null pointer

On Sun, Aug 16, 2015 at 11:53:16AM +0200, Nicolas George wrote: Consistency is good, but it is not the only aspect of convenience. Catching common bugs is another aspect, pulling in the other direction. When freeing something, there is always the question If I am freeing NULL here, is it a

Re: TextView background color: bug or misunderstanding?

Hi, On Sat, Jul 04, 2015 at 01:04:08PM +0200, Kasper Peeters wrote: I am trying to make the background colour of all TextViews white, using gtk_widget_override_background_color() This does make the background white, but it also makes the color used for selection highlight white. As a

Re: GTK+ brochure for FOSDEM

On Sat, Jan 24, 2015 at 10:07:56AM -0500, Paul Davis wrote: GTK3's CSS styling feature is a huge draw for many developers. Being able to take an understanding of themeing based on web development and apply it to native applications is really a very very nice feature. I would have talked at

Re: GTK+ brochure for FOSDEM

On Fri, Jan 23, 2015 at 10:42:28PM +, Chris Vine wrote: On Fri, 23 Jan 2015 23:24:18 +0100 Sébastien Wilmet swil...@gnome.org wrote: I said object oriented style, not GObject. You can write C code with an OO style without using GObject. What you actually said was: snip If you jump

Re: GTK+ brochure for FOSDEM

On Fri, Jan 23, 2015 at 12:29:12PM -0800, Jasper St. Pierre wrote: That seems like an extremely bizarre and specific use case to optimize for Hey, it was just a random example, to give another possible viewpoint. ___ gtk-devel-list mailing list

Re: GTK+ brochure for FOSDEM

On Fri, Jan 23, 2015 at 09:27:37AM -0800, Jasper St. Pierre wrote: The learning path for writing a GTK+ application should be: GLib - GObject (at least the basis) - a bit of GIO - and finally GTK+. All GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's important to

Re: GTK+ brochure for FOSDEM

On Fri, Jan 23, 2015 at 10:39:17AM -0500, Paul Davis wrote: Event loop programming is simultaneously completely fundamental to all user-interactive software, and as such ought to require no introduction at all, but as you note it is (pathetically) lacking from the education experienced by many

Re: GTK+ brochure for FOSDEM

On Fri, Jan 23, 2015 at 06:18:02PM +, Alberto Ruiz wrote: I don't see much of a debate there. Most people want to solve a problem, and start from the problem, not from the tool to solve it That's why the brochure begins by an introduction to GTK+ and an architecture overview. People who

Re: GTK+ brochure for FOSDEM

On Fri, Jan 23, 2015 at 01:38:05PM -0500, Paul Davis wrote: Writing GObject classes is not typically something that application developers will do. There are many apps in GNOME, written in C, full of GObject classes. Look at gedit for instance. By reading the answers of this thread, it seems

Re: GTK+ brochure for FOSDEM

On Fri, Jan 23, 2015 at 09:00:53PM +, Chris Vine wrote: You are looking at it from the perspective of a GTK+ developer and not an application developer. (I'm not a GTK+ developer, I just contribute a little) Application developers not providing applications specifically for the gnome

Re: GTK+ brochure for FOSDEM

On Fri, Jan 23, 2015 at 09:40:56PM +, Chris Vine wrote: On Fri, 23 Jan 2015 22:29:02 +0100 Sébastien Wilmet swil...@gnome.org wrote: Yes, for a small application it's another possible code architecture. But I would still recommend to write C code in object oriented style (if the C

Re: GTK+ brochure for FOSDEM

On Thu, Jan 22, 2015 at 10:51:38PM +, Alberto Ruiz wrote: I agree with Paul here, GTK+ targets people who want to do desktop apps. I would actually try to sell all the new stuff for developers like the new introspection tool, the new widgets and some of the new CSS work with snippets. One

Re: GTK+ brochure for FOSDEM

On Thu, Jan 22, 2015 at 10:01:55PM +0100, Sébastien Wilmet wrote: https://github.com/swilmet/gtk-brochure https://people.gnome.org/~swilmet/gtk-brochure.pdf I've pushed an update. I've simplified the GObject section, and added a state diagram of the GLib event loop. An event loop and event

Re: cl-cffi-gtk: A Common Lisp binding for GTK+ 3

Hi Sian, On Wed, Jan 21, 2015 at 02:27:27PM +, Sian Mountbatten wrote: I'd like to bring to your attention the Common Lisp binding for GTK+ 3 written by Dr Dieter Kaiser kai...@crategus.com. The binding is thorough and well documented. Please update your list of language bindings of

Re: GTK+ brochure for FOSDEM

On Thu, Jan 22, 2015 at 09:33:18PM +, Alberto Ruiz wrote: First of all thanks a lot for working on this! However, for a brochure about a graphical toolkit, I find it interesting that there are no GTK+ apps' screenshots. Perhaps I would suggest something less verbose and more to the

GTK+ brochure for FOSDEM

Hi, Just a quick note to announce that I've written a brochure about GLib/GTK+: https://github.com/swilmet/gtk-brochure https://people.gnome.org/~swilmet/gtk-brochure.pdf Nothing revolutionary here, some chunks of text come from the gtk.org website or from the API references [1]. But for a

Re: a new combo box

On Sat, Dec 27, 2014 at 10:52:27PM +0900, Tristan Van Berkom wrote: From a quick look at gtkcombobox.h, the only really problematic part is the tabular menu nonsense (set_wrap_width(), set_row_span_column(), set_column_span_column()). Is there any way we could get around that ? perhaps just an

Re: a new combo box

On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote: In any case, I think this misses the point I was trying to make, I think someone had to raise the obvious question: is it justified to bring in a whole new combo API ? Or can we / should we get the most out of the API we have

Re: Improve word boundaries for text widgets

On Sat, Oct 04, 2014 at 08:54:03PM +0200, Sébastien Wilmet wrote: On Sat, Oct 04, 2014 at 02:10:02PM -0400, Matthias Clasen wrote: My main motiviation is that 'we follow TR29' is much better in terms of documenting it, testing it and diagnosing bugs in than 'do what vim does'. That would

Re: Improve word boundaries for text widgets

On Fri, Oct 03, 2014 at 10:25:36PM -0400, Matthias Clasen wrote: I think I want the default in GtkTextView/Pango to stay basically Unicode. So the vfunc may be needed sooner if you want to have vim-like behaviour in GtkSourceView. What do you mean by basically Unicode? The problems in GTK+: -

Re: Improve word boundaries for text widgets

On Sat, Oct 04, 2014 at 12:30:43PM -0400, Matthias Clasen wrote: I mean that it is the right default behavior to follow Unicode TR 29. If we want to follow Unicode TR 29, then we should use the is_word_boundary PangoLogAttr attribute, see: https://bugzilla.gnome.org/show_bug.cgi?id=530405 As I

Re: Improve word boundaries for text widgets

On Sat, Oct 04, 2014 at 02:10:02PM -0400, Matthias Clasen wrote: My main motiviation is that 'we follow TR29' is much better in terms of documenting it, testing it and diagnosing bugs in than 'do what vim does'. That would work if TR29 specifies clearly the different word boundaries to use for

Re: Improve word boundaries for text widgets

On Sat, Sep 27, 2014 at 12:47:31AM -0400, Matthias Clasen wrote: I agree that we probably need a vfunc - there's different use cases that need different variants: natural language, code, xml, etc. For best results, we may even want a way to use different word breaking rules in different

Re: Improve word boundaries for text widgets

On Fri, Sep 26, 2014 at 04:37:52PM -0700, Christian Hergert wrote: I'm doing exactly this in Builder today for VIM style `w` and `b`. Ctrl+right is the same as 'e' in Vim: go to the next word end. Ctrl+left is the same as 'b' in Vim: go to the previous word start. Is there a good reason to

Improve word boundaries for text widgets

Hi, Several months ago I started working on improving the word boundaries, I've written some patches, written some comments on bugzilla in various bugs. Here is a summary, I hope it'll get more attention than in bugzilla. I would like to improve the word boundaries for the text widgets:

Re: GTK+ scene graph, API deprecations

On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote: On 16 August 2014 16:23, Sébastien Wilmet swil...@gnome.org wrote: With GskLayerContent, will it be possible to unify cell renderer and widget drawing models? To simplify significantly the GtkTreeView implementation, for example

Re: GTK+ scene graph, API deprecations

On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote: Because every time we try to clean up GtkTreeView, we break some random application. It's a widget that has twenty three gazillion use cases, and so we have to keep it a mess, because removing the mess means removing one use case, and

Re: GTK+ scene graph

Hi, Another question. With GskLayerContent, will it be possible to unify cell renderer and widget drawing models? To simplify significantly the GtkTreeView implementation, for example, and be able to insert a GtkWidget in a GtkTreeView. See: https://bugzilla.gnome.org/show_bug.cgi?id=619017

Re: A Gtk's build system ?

On Tue, 2014-08-05 at 10:35 -0300, Victor Aurélio Santos wrote: Is there a plan to write a new build system or use another existing build system for Gtk instead of Autotools ? For what it's worth, I've written a blog post some time ago:

Re: GTK+ scene graph

Thanks for the explanation. On Sun, 2014-08-03 at 01:13 +0100, Emmanuele Bassi wrote: snip yes, it was considered, and no: depth (or similar terms) won't be used. people using a canvas with 3D transformations intuitively grasp the concept of a Z axis, as well as that of a coordinate on

GTK+ scene graph

Hi, Some questions about the GTK+ scene graph ([1]). Why not reusing the height-for-width and width-for-height sizing requisition type? Will it Just Work with the constraint-based layouts? For functions like gsk_layer_set_z_position() having 'z' in the name, have you considered naming them with

Re: Tutorial on writing widgets?

Hi, On Thu, 2014-07-17 at 16:54 -0400, Rena wrote: Is there any tutorial on how to make a library that provides a GTK widget, like GtkGlExt or GtkSourceView, but for GTK+ 3? I want to write such a library, but I can't find a guide on how to do it, and existing libraries are proving too

Re: Glade crashing

Hi, On Sat, May 17, 2014 at 12:05:13PM +0200, Lanoxx wrote: I am using Ubuntu 13.10 with Glade 3.14.2. I just noticed that Glade crashes when I try to open the following glade file: A mailing list is not a good place for a bug report. Please file a bug on bugzilla, after searching if a

Re: Scrolling: be able to disable the zoom mode

On Sun, Mar 23, 2014 at 02:06:32PM +0100, Sébastien Wilmet wrote: I've filed a bug about the scrolling zoom mode: https://bugzilla.gnome.org/show_bug.cgi?id=722438 More information about the scrolling zoom mode: http://blogs.gnome.org/mclasen/2013/08/05/scrolling-in-gtk

Scrolling: be able to disable the zoom mode

Hello, I've filed a bug about the scrolling zoom mode: https://bugzilla.gnome.org/show_bug.cgi?id=722438 Without any response. So I try here on the mailing list. I still use GTK+ 3.8 on my desktop because of that. For me the zoom mode is useful only for taking a precise screenshot... I

Re: deactivate enter signal on GtkButton

Hi, On Thu, Nov 07, 2013 at 08:10:50PM +0800, Mahesh Chaudhari wrote: which one to use if I wants my button should not glow on hovering mouse pointer over the button It comes from the theme. It's a bad idea to stop a signal because you don't want the :hover effect. Regards, Sébastien

Re: Spell checking in GIO

On Mon, Oct 07, 2013 at 10:38:01PM +0200, Sébastien Wilmet wrote: The first step is to wrap enchant in GIO. More precisely, here are the two classes from gtkhtml that can go in GIO: https://git.gnome.org/browse/gtkhtml/tree/components/editor/gtkhtml-spell-language.h https://git.gnome.org

Re: Spell checking in GIO

On Wed, Oct 09, 2013 at 09:31:19AM +1100, Andrew Cowie wrote: Speaking of which, do we really need to have so many different back-ends? We made a hard decision about the input method framework requirement, maybe we should just pick a dictionary provider and go with it? The perfect dictionary

Re: Spell checking in GIO

On Wed, Oct 09, 2013 at 10:53:50PM +0200, Bastien Nocera wrote: I wouldn't want to use 2 different APIs when creating command-line/curses APIs or GTK+ though. Otherwise, whatever syntactic sugar the GObject bindings would add would be lost. And if we add the spell checking directly in GTK+, an

Re: API break in GtkAction?

On Mon, Oct 07, 2013 at 06:39:41PM -0400, Matthias Clasen wrote: I've just pushed a testcase ( https://git.gnome.org/browse/gtk+/tree/tests/teststockbuttonmenu.c) that shows things related to stock icons, buttons, menuitems and actions working as I would expect them to, including

API break in GtkAction?

Send to gtk-devel-list too. GtkAction, GtkStock, GtkUIManager etc have been deprecated. But it should still be possible to use them. On Thu, Oct 03, 2013 at 10:13:51PM +0200, Sébastien Wilmet wrote: Hello, Since the deprecation of GtkUIManager, GtkAction, GtkStock etc, it seems

  1   2   >