Re: Dropping 'fringe' pixbuf loaders

[Cosimo Cecchi]

On Mon, Sep 21, 2015 at 8:28 AM, Matthias Clasen 
wrote:

> Before doing so, I want to ask if anybody is willing to step up and
> maintain these loaders.  Note that even if we drop these from gdk-pixbuf
> itself, they can be maintained out-of-tree... one of the advantages of
> having loaders as modules.
>

Not stepping up to maintain those, but I really like Emmanuele's idea of
splitting the other modules into a separate repository on git.gnome.org; I
think there is value in keeping them all in a central location.

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

Re: Dropping 'fringe' pixbuf loaders

[Cosimo Cecchi]

On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor  wrote:

> Do we trust this code or not? If not, we should either a) sandbox it or b)
> delete it.
>
> Moving less-trusted loaders into a separate repo is a blame-the-user or
> blame-the-os-vendor move, depending on who installs them onto the system.
>

The only way to prevent the blame game you mention in a typical
distribution where everything is installed through packages would be to
stop supporting out of tree modules entirely, if I interpret your concern
correctly.

My point is that as long as that's the case, at least maintaining them in a
central location gives people an aggregation point for fixes.

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

Re: RFC: GtkPreview library

[Cosimo Cecchi]

On Tue, Jan 27, 2015 at 2:23 PM, Paul Davis p...@linuxaudiosystems.com
wrote:

 what happened to the idea of GTK being a cross-platform toolkit? you're
 seriously proposing building something as significant as a Preview widget
 around a technology that isn't even deployed on most Linux systems yet, and
 will almost certainly never be available on other platforms?


Paul, I don't think you understand what is being proposed here, and I much
dislike the aggressive tone you are imposing on this conversation.
Whether to use something different than a Wayland transport on non-Linux
platforms is entirely up for debate. I am not familiar with how Windows and
OSX implement previews, and whether integration with the native platform
APIs is desirable in those cases, but I will point out that a simple shared
memory transport can be used with Wayland, which should work fine even on
those platforms.

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

Re: RFC: GtkPreview library

[Cosimo Cecchi]

So you're effectively proposing that the transport of the data between
plugins and the widget is always Wayland, even if the session is running
under X11? That sounds like a good idea to me if it's possible to
implement. I would definitely welcome a proof of concept!

Thanks,
Cosimo

On Sun, Jan 25, 2015 at 4:21 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 We could indeed write a tiny Wayland compositor that composited a single
 wl_surface as a GTK+ widget, and I wouldn't feel too bad about it. We could
 even do it while under X11, and it might be an interesting proof of
 concept. I could do a PoC if you guys want.
 On Jan 25, 2015 8:05 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 Fair enough, those are good points.
 To rephrase my last message I am not well-versed in the details of
 subsurfaces and how they would help in this case, so I will appreciate help
 to evolve my API proposal in that direction :-)

 Cosimo

 On Sun, Jan 25, 2015 at 3:49 PM, Emmanuele Bassi eba...@gmail.com
 wrote:

 hi;

 On 25 January 2015 at 13:31, Philip Withnall phi...@tecnocode.co.uk
 wrote:

  That's why my proposal doesn't enforce this specific design; I'm
  definitely open to think more about how a multi-process design looks
  like, but I wouldn't want to block until that is figured out.
 
  To me, the security and rendering architecture of this seems pretty
 core
  in the design, so I _would_ block on figuring it out. It doesn’t feel
  like the kind of thing which can easily be bolted on or fixed
  afterwards.

 I tend to agree; we need to start designing our API with sandboxing
 and security context separation from the start, these days, otherwise
 we'll have nothing but grief (in the form of API changes or, worse,
 complete rewrites) down the line.

 ciao,
  Emmanuele.

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



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


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

Re: RFC: GtkPreview library

[Cosimo Cecchi]

On Tue, Jan 27, 2015 at 2:59 PM, Paul Davis p...@linuxaudiosystems.com
wrote:

 I understand the appeal of using existing technology (i.e. Wayland) to
 accomplish something when it appears that it will make it much easier.

 But if GTK is still at least nominally cross-platform, then surely the
 place to start is a higher level abstraction of the transport system, and
 then later to bolt wayland onto that design under the hood, rather than
 starting with Wayland and then shrugging one's hands and saying do
 something like Wayland on other platforms?


I don't see how anything I've said could be used to imply that GTK is,
nominally or concretely, not cross-platform anymore.

What is being discussed here is the possibility of using Wayland as the
implementation to communicate privately between the preview plugin process
and the main process, without a Wayland requirement for the session the
processes live in.
I'm arguing that as long as the Wayland libraries can be built on the
platforms we care about and a suitable way of sharing a buffer exists, even
if not extremely optimized, we can possibly get away without the
abstraction you're talking about.

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

Re: RFC: GtkPreview library

[Cosimo Cecchi]

On Sat, Jan 24, 2015 at 4:33 AM, Carlos Garcia Campos carlo...@gnome.org
wrote:

 I'm assuming the providers will render the contents into surfaces that
 the previewer will compose, not providers directly drawing into the
 previewer. We can share the bitmaps between processes without using
 anything like CORBA, simply using shared memory and sending the file
 descriptor with dbus. Note that providers might not be asynchronous, or
 thread safe.


I can see a few problems with this approach:
- data is not always a static bitmap. You can preview arbitrary complex
things like webpages, videos, presentations, etc. In the future even
possibly complex CAD drawings or whatnot, if a module gets written for them.
- the problem with doing this generically is that there needs a system that
notifies what has been invalidated in order to redraw, something that
forwards input events, etc.
- ideally we don't want to copy every frame while doing that

Bastien's suggestion to use (wayland) sub-surfaces sounds like a much
better fit, as they're designed specifically to address some of these
problems. My understanding is that it requires writing a small wayland
compositor in the widget itself; not sure yet what'd be involved with this.
There's also a question about what to do on backends (like X11) that don't
really support such a thing. I guess we could use XEmbed on X11, but I can
see it turning messy pretty quickly.

That's why my proposal doesn't enforce this specific design; I'm definitely
open to think more about how a multi-process design looks like, but I
wouldn't want to block until that is figured out.

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

Re: RFC: GtkPreview library

[Cosimo Cecchi]

On Tue, Jan 20, 2015 at 10:24 AM, Carlos Garcia Campos carlo...@gnome.org
wrote:

 One important thing is that preview providers should be out of process,
 since unfortunately it's very easy to make things crash with buggy files
 (which are very common). That could be done by every provider, but if we
 force that at a higher level it would be much better. That would also
 ensure that preview providers don't block the UI main thread, assuming
 the communication with the provider processes will be always
 asynchronous unconditionally.


I ultimately agree, and I wrote a paragraph to that effect in my proposal...
It's tricky to enforce this in the library, because it effectively means
inventing a way for a process to draw into another process that doesn't
look like libbonobo, and I didn't really want to go that path...

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

Re: RFC: GtkPreview library

[Cosimo Cecchi]

I moved this to the wiki:
https://wiki.gnome.org/Projects/GTK%2B/Preview

Cosimo

On Mon, Jan 19, 2015 at 11:46 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 Hi all,

 We talked in the past with other GTK developers about the possibility of
 integrating a preview library, allowing GTK applications to easily get a
 widget that represents the preview of a file. This would currently be used
 by GtkFileChooser, or a future evolution of the current class, but also by
 file managers, possibly mail clients, etc.

 I wrote a draft proposal for the architecture of the library. The master
 copy lives for now in a Google Doc free for comments here [1], but I will
 also paste it here below. I will move this to the GNOME Wiki once I have
 received the initial feedback.

 Comments welcome!

 [1]
 https://docs.google.com/document/d/1kaHZtOSUMgm6qB3FLzGNuYJIgJVAEnWMvBPDvlzNeNY/edit?usp=sharing

 Overview

 The primary goal of the feature is to be able to create an interactive
 preview of a given file, in the form of a GtkWidget, from a generic
 interface that is extensible to different mime types.
 “Interactive” means that a set of actions can be performed on the preview
 itself. For instance, when previewing a PDF document it is desirable to
 switch to previous/next page; when previewing a video or a song it’s
 desirable to play/pause, etc.
 The feature lives ideally inside GTK.

 Architecture

 The requirement of supporting the widest variety of formats possible in
 the library calls for an extensible system, where a set of modules are
 registered as preview “providers”, each handling a list of mime types. This
 also avoids the need for GTK to directly link to all the dependencies
 directly, but some providers could be distributed as part of GTK (e.g. a
 GdkPixbuf-based one for images).
 The most straightforward way to implement this is through an extension
 point with a well-defined interface that can be implemented by shared
 objects modules installed by the different libraries or applications that
 want to extend the functionality.
 It should also be possible for implementations to use a DBus interface to
 transfer the data. This makes it possible for an actual application to be
 spawned in response to a preview request, and send the data over the wire,
 which will be not as expensive as it is now when kdbus enters the picture.
 Doing this in a generic “dbus implementation” module might be hard though,
 because it’s not possible to export a GtkWidget over DBus, and is outside
 the scope of this proposal. I imagine e.g. a Totem-provided viewer to be
 able to stream the video to the library, but the Totem module would still
 know how to draw back the data it receives from the Totem process.

 Registration

 Modules can register themselves by installing a .so file into a known
 location. A design where a textual descriptor is also installed, providing
 metadata about the module capabilities is possible; otherwise there could
 be methods on the module interface to define that without the need of an
 extra file. An advantage of the descriptor file is that it makes it easy to
 e.g. load modules in priority order (by just sorting the descriptors
 alphabetically), giving the library a mechanism to predictably resolve
 conflicts in case two modules claim to handle the same mime type.

 Interface

 We need two separate interfaces; one used by the client of the library and
 one between the library and the modules.

 Client

 GtkWidget * gtk_preview_widget_new (void)
 GtkWidget * gtk_preview_widget_new_from_file (GFile *)
 voidgtk_preview_widget_set_file (GtkPreviewWidget *, GFile *)
 GFile * gtk_preview_widget_get_file (GtkPreviewWidget *)

 These are all pretty obvious; to create a preview widget you need a file.

 GtkPreviewContext * gtk_preview_widget_get_context (GtkPreviewWidget *)

 Everything that relates to the widget but is not part of the widget itself
 is split into a GtkPreviewContext object. This is effectively the entry
 point for all the actions-related operations.

 GtkPreviewContext implements GActionGroup

 GIcon * gtk_preview_context_get_icon (GtkPreviewContext *, gchar * action)
 gchar * gtk_preview_context_get_label (GtkPreviewContext *, gchar * action)
 gchar * gtk_preview_context_get_description (GtkPreviewContext *, gchar *
 action)

 By implementing GActionGroup, GtkPreviewContext can be used by the client
 to enumerate actions and create UI elements with them. There are no
 assumptions on where the actions come from; for instance, GtkPreviewContext
 could add by default an “open” action that is handled in a generic way
 entirely outside of the module. Similarly, applications could add their own
 actions on top of the stock.
 Higher level objects can be built on top of these two simple classes. For
 instance, a GtkPreviewDialog could be created that displays the preview
 widget in a GtkScrolledWindow with actions in a GtkActionBar below it.

 Module

 GLib and GIO offer low-level and higher

RFC: GtkPreview library

[Cosimo Cecchi]

Hi all,

We talked in the past with other GTK developers about the possibility of
integrating a preview library, allowing GTK applications to easily get a
widget that represents the preview of a file. This would currently be used
by GtkFileChooser, or a future evolution of the current class, but also by
file managers, possibly mail clients, etc.

I wrote a draft proposal for the architecture of the library. The master
copy lives for now in a Google Doc free for comments here [1], but I will
also paste it here below. I will move this to the GNOME Wiki once I have
received the initial feedback.

Comments welcome!

[1]
https://docs.google.com/document/d/1kaHZtOSUMgm6qB3FLzGNuYJIgJVAEnWMvBPDvlzNeNY/edit?usp=sharing

Overview

The primary goal of the feature is to be able to create an interactive
preview of a given file, in the form of a GtkWidget, from a generic
interface that is extensible to different mime types.
“Interactive” means that a set of actions can be performed on the preview
itself. For instance, when previewing a PDF document it is desirable to
switch to previous/next page; when previewing a video or a song it’s
desirable to play/pause, etc.
The feature lives ideally inside GTK.

Architecture

The requirement of supporting the widest variety of formats possible in the
library calls for an extensible system, where a set of modules are
registered as preview “providers”, each handling a list of mime types. This
also avoids the need for GTK to directly link to all the dependencies
directly, but some providers could be distributed as part of GTK (e.g. a
GdkPixbuf-based one for images).
The most straightforward way to implement this is through an extension
point with a well-defined interface that can be implemented by shared
objects modules installed by the different libraries or applications that
want to extend the functionality.
It should also be possible for implementations to use a DBus interface to
transfer the data. This makes it possible for an actual application to be
spawned in response to a preview request, and send the data over the wire,
which will be not as expensive as it is now when kdbus enters the picture.
Doing this in a generic “dbus implementation” module might be hard though,
because it’s not possible to export a GtkWidget over DBus, and is outside
the scope of this proposal. I imagine e.g. a Totem-provided viewer to be
able to stream the video to the library, but the Totem module would still
know how to draw back the data it receives from the Totem process.

Registration

Modules can register themselves by installing a .so file into a known
location. A design where a textual descriptor is also installed, providing
metadata about the module capabilities is possible; otherwise there could
be methods on the module interface to define that without the need of an
extra file. An advantage of the descriptor file is that it makes it easy to
e.g. load modules in priority order (by just sorting the descriptors
alphabetically), giving the library a mechanism to predictably resolve
conflicts in case two modules claim to handle the same mime type.

Interface

We need two separate interfaces; one used by the client of the library and
one between the library and the modules.

Client

GtkWidget * gtk_preview_widget_new (void)
GtkWidget * gtk_preview_widget_new_from_file (GFile *)
voidgtk_preview_widget_set_file (GtkPreviewWidget *, GFile *)
GFile * gtk_preview_widget_get_file (GtkPreviewWidget *)

These are all pretty obvious; to create a preview widget you need a file.

GtkPreviewContext * gtk_preview_widget_get_context (GtkPreviewWidget *)

Everything that relates to the widget but is not part of the widget itself
is split into a GtkPreviewContext object. This is effectively the entry
point for all the actions-related operations.

GtkPreviewContext implements GActionGroup

GIcon * gtk_preview_context_get_icon (GtkPreviewContext *, gchar * action)
gchar * gtk_preview_context_get_label (GtkPreviewContext *, gchar * action)
gchar * gtk_preview_context_get_description (GtkPreviewContext *, gchar *
action)

By implementing GActionGroup, GtkPreviewContext can be used by the client
to enumerate actions and create UI elements with them. There are no
assumptions on where the actions come from; for instance, GtkPreviewContext
could add by default an “open” action that is handled in a generic way
entirely outside of the module. Similarly, applications could add their own
actions on top of the stock.
Higher level objects can be built on top of these two simple classes. For
instance, a GtkPreviewDialog could be created that displays the preview
widget in a GtkScrolledWindow with actions in a GtkActionBar below it.

Module

GLib and GIO offer low-level and higher-level APIs to setup a library
extension point. Assuming that part of the problem is solved, let’s define
GtkPreviewModule as the interface that all modules need to implement.

GtkPreviewModule * gtk_preview_get_module_for_file (GFile *)

Re: Deprecated widgets on Stack Overflow [was: a new combo box]

[Cosimo Cecchi]

On Wed, Dec 31, 2014 at 1:01 PM, Philip Chimento philip.chime...@gmail.com
wrote:

 I would hazard a guess that most people don't load up the docs' index
 page, but instead land on pages directly by googling - and so don't see the
 Deprecated Widgets section. For example if I google gtk list widget a
 GtkList tutorial page is the fourth result. [1] Although admittedly, that
 doesn't explain why someone wouldn't click on one of the perfectly fine top
 three results.


What's bad is that for such a search the third result, and the only one
from gtk.org, which I would consider a reputable source if I'm looking for
information on GTK, is a really old tutorial for GTK 1.2 [1].
Searching for gtk tutorial also gives suboptimal results, where none of
the hits in the first page refers to the currently maintained version
(first result is coming from developer.gnome.org, but it's very outdated
[2]).

I realize keeping those guides up to date is a lot of work, but I think we
should at least purge information that is actively misleading, such as the
GTK 1.2 guide, or clearly mark it as deprecated with links to newer
alternatives, which do exist on developer.gnome.org.

[1] http://www.gtk.org/tutorial1.2/gtk_tut-31.html
[2] https://developer.gnome.org/gtk-tutorial/stable/

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

Re: a new combo box

[Cosimo Cecchi]

On Tue, Dec 30, 2014 at 2:26 AM, Philip Chimento philip.chime...@gmail.com
wrote:

 Assuming that questions on Stack Overflow are an approximate poll of what
 application authors do - many application authors go to the documentation
 and do exactly that. (And often don't bother to read any further - I've
 often enough seen questions about a deprecated widget such as GtkList which
 was selected purely based on its name.)


We are getting a bit off the topic of the thread, but this is an
interesting observation.

Can you link to some examples of this? I would be curious why that is the
case - i.e. which medium was used to consult the documentation, because on
the website deprecated classes are quite clearly marked in a separate
section at the bottom of the reference (
https://developer.gnome.org/gtk3/unstable/).

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

Re: a new combo box

[Cosimo Cecchi]

On Mon, Dec 29, 2014 at 1:53 AM, Matthias Clasen matthias.cla...@gmail.com
wrote:

 I am a bit disappointed by the turn this discussion has taken - I was
 hoping people would try the code I pointed to and let me know what
 they think and point out problems (thanks to Tim for doing just that).


Some other comments in addition to what Timm and Emmanuele already said:
- gtk_combo_remove_item() and gtk_combo_set_active() should probably return
a gboolean for the case the ID is not found. Alternatively (or in addition
to that), a gtk_combo_has_item() API could probably be added too
- what is the purpose of the inverted property of GtkComboRow? It doesn't
seem to be used in the class as far as I can see
- it would be nice to share the key press event code with the one in
GtkSearchEntry instead of duplicating it
- how does gtk_combo_add_group() behave when called on a group ID that
already exists? I assume it just sets the new value on the existing group
properties, but then the method name is a bit misleading
- consider adding a gtk_combo_remove_group() that takes a group ID

Finally, I think the widget exacerbates one of the problems with
GtkPopovers - the fact that they can't draw outside of the parent window.
In testnewcombo this is visible in the With Gropuping example when G 3
is selected; the show more button is drawn half cut with the default
window size on my laptop.

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

Re: a new combo box

[Cosimo Cecchi]

On Mon, Dec 29, 2014 at 1:09 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me
 stunned. Why should I use one instead of the other?


I doubt application authors choose which widget to use by reading type
names in API references; if you're following a style guide like the HIG,
the recommendation will come from there.
Other times you will want a widget that looks/works like one you've seen
elsewhere, and the visual/behavioral difference will make it obvious why
there are two different classes.

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

Re: a new combo box

[Cosimo Cecchi]

Thanks, Matthias for working on this, it looks great!
It's pretty clear to me that this widget is different enough from the
current combobox that using the old API and pushing the new design on every
current client is not a good idea - in the same way that GtkPopover was
made a different widget than GtkMenu. I especially welcome the departure
from cell renderers, finally!

What to do with the current GtkComboBox widget moving forward is a
different conversation in my opinion; are there any important use cases
that are not covered by the new widget? Deprecating the old API in GTK3 and
removing it in GTK4 would be the way similar things have been done in the
past.

Cosimo

On Sat, Dec 27, 2014 at 9:02 PM, Matthias Clasen matthias.cla...@gmail.com
wrote:

 Hi,

 over Christmas, I had some for a little side project, a  new combo
 box. It is based on these mockups:

 https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png

 One question I need some feedback on is naming: We currently have
 GtkComboBox and
 GtkComboBoxText. I've gone with GtkCombo for now, which has the
 downside that there is a widget by that name in gtk2. Alternatives
 might be GtkChoice or GtkComboButton (with a possible avenue for
 making the list-of-choices available for direct embeeding as
 GtkComboWidget later).

 There are some lose ends in the code, like the interaction of grouping
 and search, but it is complete enough to give it a try and evaluate
 the design. If you want to try it, the code is in the wip/combo
 branch, and there is a testnewcombo test app with some examples.

 I'm off for a few days now - would be great to hear some feedback when
 I come back.

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

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

Re: Memory tracking in GJS

[Cosimo Cecchi]

On Tue, Feb 25, 2014 at 11:08 AM, Bastien Nocera had...@hadess.net wrote:

 On Mon, 2014-02-24 at 13:56 -0800, Cosimo Cecchi wrote:
  Thanks all for your inputs; I now posted a first iteration of a patch
  that implements the suggestions of this thread here
 
 
  https://bugzilla.gnome.org/show_bug.cgi?id=725099

 This is pretty similar to Giovanni's patch, no?

 https://bugzilla.gnome.org/show_bug.cgi?id=724797


Only partly; the last patch of Giovanni's just calls JS_MaybeGC(), which
won't look at the memory allocation as reported by the kernel, whereas my
patch will schedule a call to gjs_maybe_gc(), which also has the logic
Colin linked to before. I also schedule that from a bunch more places than
Giovanni's patch did.

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

Re: Memory tracking in GJS

[Cosimo Cecchi]

Thanks all for your inputs; I now posted a first iteration of a patch that
implements the suggestions of this thread here

https://bugzilla.gnome.org/show_bug.cgi?id=725099

Cheers,
Cosimo


On Thu, Feb 20, 2014 at 6:09 AM, Colin Walters walt...@verbum.org wrote:

 On Wed, Feb 19, 2014 at 8:50 PM, Cosimo Cecchi cosi...@gnome.org wrote:

 Hi all,

 The state of garbage collection for typical GTK/JS applications is pretty
 sad these days.


 It's worth a comparison with (C)Python.   In some ways, Python's hybrid
 refcount + GC is the worst of both worlds - you have the constant overhead
 (cacheline bouncing, etc.) hit of refcounting, with the unpredictability of
 GC as soon as you happen to make a reference cycle.

 Except for the case of objects allocated in local function scope.  This
 case is a very important one for us.  Many of my applications do this a
 *lot* - lots of Gio.File instances for example.  And stuff like Cairo
 surfaces.   (C)Python will deterministically clean these up at the end of
 the function - they don't escape, their refcount drops to 0.

 It'd be quite nice if the Spidermonkey compiler attempted to do escape
 analysis and deterministic cleanup when it could.

 The problem is that for a native GObject wrapped into a JSObject there are
 effectively two sets of allocations: those internal to GObject and those
 needed to wrap it into a JSObject. While in the latter case the garbage
 collector will keep track of those segments, we currently never forward the
 GObject allocations/payload size to the garbage collector.


 I don't think we can ever do that in a reliable way.  At least with the
 current design of GObject.

 Now...the Samba guys are heavily invested in talloc (
 http://talloc.samba.org/talloc/doc/html/index.html ) which gives this
 kind of information for effectively free ( talloc_get_size () ).

 I've thought sometimes about having an optional talloc-like API for GLib,
 but it would be really invasive.

 The result is that, especially with large objects (e.g. pixbufs, cairo
 surfaces, ...) there's a huge difference between what mozjs thinks is the
 memory situation and the reality, and an application can effectively run
 out of system memory before the garbage collector kicks in. Firefox gets
 away with it because JS code only needs to allocate memory outside of the
 garbage collector very rarely, and those cases are handled internally by
 manually updating the counter.


 It depends on the JS code, but certainly a lot of real-world web pages do
 heavy DOM manipulation which does involve lots of nontrivially-sized native
 objects.  This is the case that every web browser is optimized for, because
 they have to.

 Some ideas that have been floating around:
 * have special methods on interesting objects to explicitly release
 memory. gnome-shell for instance does this already when using Cairo from
 within JS, for exactly the same reason.


 I think there's no question we should allow this.  It's a bit ugly, but

 * override the GLib memory allocator with e.g. g_mem_set_vtable() to
 intercept allocations and signal the garbage collector. Problems: doesn't
 work for things that use e.g. static constructors, is tricky for
 re-entrancy, libraries like GdkPixbuf might not use the GLib allocator for
 image payloads, doesn't work with the slice allocator.


 I'd really rather investigate something like talloc-for-glib if we were to
 try going down this route.  It would have the potential to improve
 performance of pure C apps as well.

 * keep track of memory allocated in GJS itself. We can use GType to query
 the size of the instance, class and even the size of private data. This
 still doesn't include additional allocations inside the object itself, such
 as strings, buffers and payloads. We could track those case-by-case by e.g.
 overriding constructors in the binding for interesting pixbuf-like types
 (ugh), or have a way to query that information from the type
 system/introspection itself.


 I just don't think this one is going to scale.

 Any other ideas?


 Beyond the above, I think ultimately this needs help from the kernel.
  That's where I was going with

 https://git.gnome.org/browse/gjs/commit/?id=7aae32d1df14af87e9a31c785447b27012b64af9
 Here the kernel is keeping track of our total memory usage, both JS and C.

 I feel this is a fundamental enough issue that there must be a good way to
 design a generic solution.


 It all gets a lot more interesting when you consider *multiple* garbage
 collected processes on the system.  I think this is still an open research
 area.


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

Memory tracking in GJS

[Cosimo Cecchi]

Hi all,

The state of garbage collection for typical GTK/JS applications is pretty
sad these days. mozjs will execute a garbage collection run when it thinks
around 30MB of allocations have been done.
The problem is that for a native GObject wrapped into a JSObject there are
effectively two sets of allocations: those internal to GObject and those
needed to wrap it into a JSObject. While in the latter case the garbage
collector will keep track of those segments, we currently never forward the
GObject allocations/payload size to the garbage collector.
The result is that, especially with large objects (e.g. pixbufs, cairo
surfaces, ...) there's a huge difference between what mozjs thinks is the
memory situation and the reality, and an application can effectively run
out of system memory before the garbage collector kicks in. Firefox gets
away with it because JS code only needs to allocate memory outside of the
garbage collector very rarely, and those cases are handled internally by
manually updating the counter.

Some ideas that have been floating around:
* have special methods on interesting objects to explicitly release
memory. gnome-shell for instance does this already when using Cairo from
within JS, for exactly the same reason.
* override the GLib memory allocator with e.g. g_mem_set_vtable() to
intercept allocations and signal the garbage collector. Problems: doesn't
work for things that use e.g. static constructors, is tricky for
re-entrancy, libraries like GdkPixbuf might not use the GLib allocator for
image payloads, doesn't work with the slice allocator.
* override/intercept allocations with a LD_PRELOAD hack. Pretty evil and
brittle.
* keep track of memory allocated in GJS itself. We can use GType to query
the size of the instance, class and even the size of private data. This
still doesn't include additional allocations inside the object itself, such
as strings, buffers and payloads. We could track those case-by-case by e.g.
overriding constructors in the binding for interesting pixbuf-like types
(ugh), or have a way to query that information from the type
system/introspection itself.

Any other ideas? I feel this is a fundamental enough issue that there must
be a good way to design a generic solution.

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

Re: notifications in gtk

[Cosimo Cecchi]

On Tue, Nov 6, 2012 at 10:39 AM, Olav Vitters o...@vitters.nl wrote:

 Would a Qt/KDE application be able to show notifications as well? Would
 this require freedesktop.org work, or is the intention to keep this
 limited to GNOME shell implementation?

I don't think this proposal wouldn't change the current state of
things for Qt/KDE applications - the org.fdo.Notifications DBus
protocol we use today would still be supported as a fallback.

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

Re: Adding gtkparasite to gtk?

[Cosimo Cecchi]

On Tue, 2012-02-14 at 16:25 +, Richard Hughes wrote:
 I think gtkparasite is a really useful tool for GTK developers. It's
 currently hosted in github, and the upstream seems unwilling to port
 to GTK3, and consequently there are over a dozen forks of the project
 in various states of maintenance.
 
 I'm going to suggest merging in gtkparasite to modules/ in gtk. This
 means it's kept up to date with the latest GTK codebase, and we can
 start to recommend its use to developers and hackers. So, any
 objections?

I use this often, having it built-in in GTK would be great. If the
original upstream developers agree, huge +1 here.

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

Re: GTK+ 3.3.4 released

[Cosimo Cecchi]

On Tue, 2011-11-22 at 10:59 +, Bastien Nocera wrote:
 On Mon, 2011-11-21 at 20:03 -0500, Matthias Clasen wrote:
  * GtkApplication no longer uses gtk_main internally 
 
 What do we replace g_main_quit() with then?
 
 The documentation for g_application_release() doesn't inspire
 confidence:
 http://developer.gnome.org/gio/unstable/GApplication.html#g-application-release
 
 g_object_unref()? If g_application_release() is the correct call (as the
 docs for g_application_set_inactivity_timeout() [1] makes it sound,
 could the docs please be changed?

I think the idea is things should just work if you add the toplevel
windows of the application to the GtkApplication instance (via
gtk_application_add_window or gtk_window_set_application); when the last
window is destroyed, the mainloop will quit.

For more complex cases, e.g. if you want to defer windows creation
asynchronously or if you need to run as a headless service you have to
use g_application_hold/release.


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

Re: Sharing the places sidebar between Nautilus and GTK+

[Cosimo Cecchi]

Hi Federico,

Generally, this sounds like a good plan to me. I have some comments
below.

On Tue, 2011-09-06 at 17:44 -0500, Federico Mena Quintero wrote:

[...]

 4. See what common, public interfaces we need.  For example,
 
   nautilus_window_set_initiated_unmount (sidebar-window, TRUE);
 
 seems like it could be replaced with a signal on the GtkPlacesSidebar
 class, and then Nautilus can start a spinner or whatever when an unmount
 operation starts.  Another common interface would be something like
 gtk_places_sidebar_select_path (sidebar, file:///foo/selected) to
 highlight a particular item.

IIRC nautilus_window_set_initiated_unmount() is basically a hack to
redirect a specific NautilusWindow to $HOME instead of closing it when
it's opened at a mount location and the mount disappears as a
consequence of being unmounted from inside the same window (as there can
be multiple windows in Nautilus pointing to a mount at the same time),
so probably this is not something useful to replicate in the
single-window GtkFileChooser.

 5. See what nautilus-isms *should* be doable with plain GIO, and see if
 there is anything else that Nautilus needs to do about them via signals;
 maybe for something like
 
   nautilus_file_operations_mount_volume_full (NULL, volume,
   volume_mounted_cb,
   G_OBJECT (sidebar));

As far as I remember, the only thing that those nautilus wrappers add to
using plain GIO is checking for trash files on the mounted volumes (and
prompting to the user a dialog asking if the trash should be emptied
before unmounting if so).

 6. See what things should be available or not in the file chooser...
 when dropping files on the shortcuts bar, Nautilus can do
 
   nautilus_file_operations_copy_move (uris, NULL, drop_uri,
   real_action, GTK_WIDGET (tree_view),
   NULL, NULL);
 
 
 Same thing for
 
   nautilus_file_operations_empty_trash (GTK_WIDGET (sidebar-window));

So, first of all we should think about whether this kind of interactions
are desirable in a file chooser. I don't think GtkFileChooser should be
a full-fledged file manager, so I would just disable e.g. copy/move
while porting code to GTK+.

On the other hand, other operations like emptying the trash might make
sense and exposing them in GTK+ currently means either copying a lot of
file operations code from Nautilus into GTK+, or using the DBus
org.gnome.Nautilus.FileOperations interface as Alexander suggested.

[ I think what I would love to see in my dreams for this is a stateful
file operations stack in GIO, allowing to have a central GTK+ UI to
display completed/ongoing transfers and notifications embedded in the
shell (to be used e.g. for browser/IM file transfers as well), but it
looks like a lot of work :) ]

 One little caveat: that part of Nautilus is GPL, and GTK+ is LGPL,
 although it *seems* that the places sidebar code may initially have come
 from GTK+ and then reworked heavily.  I haven't checked the history
 closely.  What do we do about this?

The git history suggests the initial code for the sidebar was
contributed by Jamie McCracken, but it doesn't mention whether it comes
from GTK+ [1]. As far as my contribution to that code goes, it's fine
for me to relicense those parts to LGPL, but maybe we should ask the
other contributors as well.

[1]
http://git.gnome.org/browse/nautilus/commit/src/nautilus-places-sidebar.c?id=977c0f99380c111749b04c20b34113f635d1d0e7

Cheers,
Cosimo

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

Re: Sharing the places sidebar between Nautilus and GTK+

[Cosimo Cecchi]

Hi Jannis,

On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:

 To be honest, I think we can do better than this. The user experience
 offered by the current places sidebar is far from ideal IMHO. In
 Nautilus 3.x 
  
   * the sidebar has no mount/eject progress indicators,
   * the eject buttons do not look/feel clickable, i.e., they don't
 change their appearance on hover events, 

[ This should have been fixed now if you use a recent enough GTK+ and
Nautilus ]

 I realize that, aside from the code still being somewhat rough and
 imcomplete, this is nothing we'd want to stuff into GTK+. In
 particular, faking the look of a tree view with custom widgets may seem
 like a hack to most people (even though standard GTK+ drawing routines
 are used). On the other hand it is fun to use and shows how the places
 sidebar *could* work IMHO:
 
   * progress indicators for async operations, 
   * real mount/eject/cancel buttons ('cuz spinners alone are not
 enough),
   * individual row/button highlighting on hover,
   * keyboard navigation works (even switching between rows and
 buttons is possible), 

I agree with these points, even if some of those might be possible to
implement with cell renderers and a tree view; to me, another added
bonus of not using a GtkTreeView but a custom container and a separate
widget for each row is it allows themes to easily style different rows,
which is used e.g. in the Documents mockup [1] and might not be very
easy to do otherwise.

[1]
http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/documents/documents-sidebar.png

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

Re: New GTK+ website design

[Cosimo Cecchi]

On Wed, 2011-04-20 at 21:31 +0100, Martyn Russell wrote:

  Two other suggestions:
  - I think the home page should mention Javascript among the bindings,
  which is getting a lot of traction nowadays (more than Perl for
  instance).
 
 We have a bindings page. Was there something specific you wanted to 
 mention here that covers more than the language bindings page?

No, I was just thinking out loud that mentioning Perl as the first
language binding in the home page sounded a bit backwards given the
current trends in the GNOME community (no offense intended, I don't
really have any idea of how many GTK+ applications are developed in
Perl).
Also, if the versions table in the binding page is up to date,  Perl
bindings don't seem to be 3.0 compatible yet.

  - It would be nice to have some screenshots updated to GNOME3/GTK3
  styles.
 
 I agree. I will steal some from the gnome 3 live.gnome.org pages unless 
 someone can point me to something useful?

Screenshots from the official website or from l.g.o should be just fine,
or you can run the live image and make some if you're looking for
something different (or ask around...I can make some too if you want).

Thanks,
Cosimo

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

Re: New GTK+ website design

[Cosimo Cecchi]

Hi Martyn,

On Tue, 2011-04-19 at 15:30 +0100, Martyn Russell wrote:

 There are a few things to decide on, so I will try to get some consensus 
 from you all before making the final decision on these points:
 
   1. The titles are available in blue (default) or red. If you append
  ?red to the link you can see them in red. What do people prefer
  here? I quite like the blue now.

I think I like the blue better too.

   2. The features page has 2 approaches. One is with next/previous
  buttons to go through the features. The other lists them as we
  did before. What do people prefer?

I feel that next/previous approach is a bit confusing, as the buttons
are not really discoverable and it doesn't give an overview of all the
items at a glance, which I think is important for such a prominent page.
I also feel the layout of the other page is a little too crowded at a
first sight, but not being a web designer I don't have concrete
suggestions to improve it (and I prefer it over the former anyway).

Two other suggestions:
- I think the home page should mention Javascript among the bindings,
which is getting a lot of traction nowadays (more than Perl for
instance).
- It would be nice to have some screenshots updated to GNOME3/GTK3
styles.

Cosimo

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

Re: Breaking things in git master...

[Cosimo Cecchi]

Hi David,

On Sat, 2010-06-12 at 08:26 -0400, David Zeuthen wrote:

 I don't think it's customary to mail the list about such changes on
 master, is it? I mean, I didn't see such notices for the few other ABI
 breaks in this cycle already.

The fact that in other cases there have been no notices it doesn't mean
it's a good policy not to send them anyway...

I think Richard has a point in this case, as AFAICS it's a change in a
fundamental construct of the API, that requires patching again pretty
much every application that has already been ported to GDBus.

I wouldn't have liked it if I had discovered this just before making a
release :)

Cheers,

Cosimo

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

Re: GtkNotebook scrolling usability

[Cosimo Cecchi]

On Thu, 2010-03-11 at 07:27 -0600, Cody Russell wrote:
 On Thu, 2010-03-11 at 09:20 +, Alberto Ruiz wrote:
   If there ends up being a bug report about this, please share the bug
   number.  And hopefully we can get some usability nerds involved in
   this decision.
  
  I agree with Sandy here, I would leave this decision up to the
  usability guys. 
 
 That's kind of why I was bringing it up on the mailing lists.  Is there
 a better list to post on to get usability people respond?

usabil...@gnome.org looks promising :)

Ciao,

Cosimo

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

Re: GTK+ at the UX Hackfest

[Cosimo Cecchi]

On Mon, 2010-03-01 at 16:44 +0100, Piñeiro wrote:

 In the gtk side, I don't know much about the XSettings, but I suppose
 that you are talking more general, and XSetting will manage all the
 gtk modules to be loaded (engines, and so on). So XSettings would have
 the lists of modules instead of the envvar, and inform to the
 applications that this setting has changed. In this case is just
 load/unload the a11y modules as any other gtk modules.

AFAIK GTK+ already reads the XSettings variable and loads modules
accordingly in gtk_init(). The filling of that property is currently
done by gnome-settings-daemon.

Cheers,

Cosimo

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

Re: Thumbnailing service project; opinions, suggestions?

[Cosimo Cecchi]

Hi Mark,

On Tue, 2009-10-20 at 16:34 +0200, Mark wrote:

 Now can we please quit bashing the idea that there will be 2
 thumbnailing services in a few months time and can i get some
 constructive feedback about the ideas in my first post?
 Can i get the:
 - Git
 - gnome sub domain
 - blog for this project on planet gnome and/or gtk

gtk-devel-list is *really* not the right place for this kind of
requests. Please read [1] for information about the GIT account
requests, [2] for Planet GNOME and [3] for the GNOME website.
Anyway, it seems to me that not having these kind of resources available
right now (or even not having them at all) should not block any
development of your project.

For what concerns the project itself, I don't like see people
duplicating efforts; as others already told you, I really can't see the
point of rush-writing a daemon that will be, in your own words, less
functional than something which is already widely used in two big
platforms and which has a well-defined spec many people already agreed
upon. Unless you see something so fundamentally broken in the
ThumanailerSpec or in Tumbler that could only be solved with a rewrite
from scratch of everything.

If I were you, I would really make a step back and reconsider what other
people proposed you, be it a specialized thumbnailer for some format, or
a library with optimized thumbnailing algorithms with a demo test-drive
thumbnailer attached.

[1] http://live.gnome.org/NewAccounts
[2] http://live.gnome.org/PlanetGnome
[3] http://live.gnome.org/Sysadmin/WebSites

Regards,

Cosimo

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

Re: GLib plans for the next cycle

[Cosimo Cecchi]

On Mon, 2009-04-20 at 12:45 -0400, David Zeuthen wrote:

 That would give you a nice circular dependency if xdg-open(1) is ever
 ported to use GIO [1] which is not at all unlikely...
 
  David
 
 [1] : under GNOME, xdg-open(1) uses gnome-open(1) which AFAICT uses
 gnome-vfs2...

gnome-open already uses GIO since 2.24 [1] so yes, we would have that
loop already. OTOH, as libgnome depends on GConf, if you have gnome-open
available, you're likely to also have GConf already installed.

[1]
http://svn.gnome.org/viewvc/libgnome/trunk/libgnome/gnome-open.c?view=markup

Ciao,

Cosimo

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

Re: Top-level include files

[Cosimo Cecchi]

On Wed, 2008-12-17 at 09:17 -0500, Morten Welinder wrote:

 So: what header files are meant to be included by applications?  Where is this
 information documented?

AFAIK it's not clearly documented anywhere, but in addition to the
toplevel headers, you should always include gdk/gdkkeysyms.h,
glib/gi18n.h, glib/gi18n-lib.h and glib/gstdio.h if the function
contained in these headers are required by the application/library
including them.

I don't know the reason why these are not included in the toplevel
header though (and I'm also not sure whether there are more headers that
should be included separately).

Cheers,

Cosimo

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

Re: Moving Open with to the platform

[Cosimo Cecchi]

On Tue, 2008-03-18 at 14:02 -0600, Federico Mena Quintero wrote:
 Hi,
 
 Right now, the Open with another application dialog lives in
 nautilus/libnautilus-private/nautilus-open-with-dialog.[ch].  This
 dialog uses the machinery in GIO's GAppInfo to figure out which apps can
 be used to open a file of a certain MIME-type.
 
 There's a long-standing annoyance in Firefox, where it implements open
 with by starting a file chooser in /usr/bin.  Now, if you complain
 about the file chooser *right here* I will ignore your mail :)  My point
 is that it would be nice if the open with GUI were available to all
 apps, not just Nautilus.
 
 We could do a few things:
 
 * Move nautilus-open-with-dialog.[ch] into GTK+.  From a super-quick
 read of the code, this uses no Nautilus-only stuff except for some of
 libeel's convenience error dialogs, and some the MIME info changed
 signal.
 
 * Leave the dialog in place inside Nautilus, and provide a D-Bus service
 for the open with GUI.  I'm 51% leaning towards this option, since
 then this would have a chance of working with a desktop-specific GUI,
 depending on your choice of desktop environment --- aside from promoting
 the use of D-Bus for this kind of stuff.
 
 Thoughts?
 
 Oh my god, this is a nice little project for the Summer of Code... it
 would involve figuring out the above, and also changing Firefox to use
 it :)

Hi Federico,
I started working some time ago on a similar request for Epiphany [1],
and I think this may be useful to other applications too.
On the other hand, there are requests [2] for a Nautilus D-Bus API not
just for this task, and it would be a good idea to implement it (maybe
even as a standardized spec for file managers?).
I also lean towards the D-Bus API, as that would potentially bring much
more integration across the desktop, but I have to say that having this
in GTK+ could allow creating nicer UIs for this kind of things.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=163827
[2]
http://mail.gnome.org/archives/nautilus-list/2008-March/msg00047.html

Cheers,

Cosimo

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