Re: An alternative to gdk-pixbuf

[Christian Hergert]

On 09/05/2018 06:57 PM, Nicolas Dufresne wrote:
> I've replied to a comment about sandboxing image loading to prevent
> possible crash buffer overflow from happening. You are now focusing on
> an optimization. I believe you should start a new thread.

It's relevant because it is the same as the bubblewrap case. You pass an
FD to the mmap'able file across the IPC boundary.

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

Re: An alternative to gdk-pixbuf

[Christian Hergert]

On 09/05/2018 06:18 PM, Nicolas Dufresne wrote:
> Is there any benchmark that would justify this added complexity ? Also,
> there will be more context switch, so cache misses will take more time
> then just loading the icon directly.

Just because you've decoded into a non-shareable page of memory doesn't
mean it wont swap and be trivialized into the same as the cached case
but with everything else worse.

Also, read-only caches can have the benefit of shoving the index table
into the head of the file and embedding it in the inode ensuring that
even your lookup table is fast and share-able.

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

Re: An alternative to gdk-pixbuf

[Christian Hergert]

On 09/05/2018 05:03 PM, Nicolas Dufresne wrote:
> 
> For foreign image, yes, but for system icons, that's just an overhead.

System icons should be using mmap'able caches that avoid any runtime
overhead and allows read-only page-sharing between processes.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Christian Hergert]

On 06/01/2018 08:10 AM, xclae...@gmail.com wrote:
> Disclaimer: I'm not a GLib maintainer so this email is only about
> opening the discussion. There is no decision made yet.
> 
> Opinions?

I think the risk area is python3 support on some commercially supported
distributions. Although, that is probably in better shape now than it
was a year ago.

Also not a maintainer, but +1 for the switch.

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

Re: Giving GtkPane more than 2 children?

[Christian Hergert]

On 05/11/2018 01:57 PM, Paul Davis wrote:
> Does your new pane correctly restore the divider positions? The existing
> GtkPane fails to be able to restore the pane divider position precisely.
> The reasons why are fairly obvious once you dive into the code. I wrote
> a new (GTK+2) pane widget for Ardour, too.

The allocations are distributed in a series of stages that allow us to
prioritize what matters.


https://gitlab.gnome.org/GNOME/libdazzle/blob/master/src/widgets/dzl-multi-paned.c#L198

It only "pins" a value between two children when the user manually drags
a handle. Everything else is handled appropriately given the features we
have available to us in gtk3 (natural sizes, HfW/WfH, h/vexpand, etc).

I avoided using percentages between children because in practice it felt
jittery under resize. But since we use natural size + expand and what
not, the typical resize case is attractive.

If you need persistence of settings between runs, there are
child-properties for everything.

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

Re: Giving GtkPane more than 2 children?

[Christian Hergert]

On 05/10/2018 11:46 AM, Ryan Gonzalez wrote:
> 
> In the past, I've come upon the situation of wanting *more* than two
> panes. When I look this up, I usually see people wiring together
> multiple GtkPanes. Would the GTK+ devs be interested in a merge request
> to add support for multiple panes? 
> 


https://gitlab.gnome.org/GNOME/gtk/issues/545
https://gitlab.gnome.org/GNOME/libdazzle/blob/master/src/widgets/dzl-multi-paned.c

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

Re: gtk3 public API requests

[Christian Hergert]

On 04/05/2018 04:03 AM, Jonas Ådahl wrote:
> Is it not possible to some how use a _move_to_rect() API, and use some
> hint we can assume means it needs to be movable, and until xdg_popup is
> further extended, make the assumption that we should for now use
> subsurfaces?

I would expect that creating alternate API to say "hey this is movable"
and then ensure that gtk_window_real_realize() uses that to ensure a
subsurface is used on Wayland would have the same effect.

And that is equally okay to me as getting set_use_subsurface().

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

Re: gtk3 public API requests

[Christian Hergert]

On 04/05/2018 01:32 AM, Jonas Ådahl wrote:
> The reason for moving away from using subsurfaces for various things is
> that they cannot be positioned properly when they extend outside the
> parent window (they tend to sometimes go partly off-screen), and should
> rather use xdg_popup+xdg_positioner instead.

The problem with that approach, at least if my experience using things
is an accurate representation of the design, is that it's quite
difficult to change or reposition the xdg_popup without first unmaping
the widget.

For example, imagine a popup that can grow in both directions
horizontally, but stay anchor'd to a position off-center.

  | original size here ... ...   |
 ++--+---+
 ||dx anchor here|   |
 ||  |   |
 ++--+---+
 | new sizedx anchor still here  |

I've yet to get this to work with the popup without first hiding the
window which gives this really annoying flicker.

But when using a subsurface, it basically Just Works™.

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

gtk3 public API requests

[Christian Hergert]

Hey everyone,

I'm lobbying to make 2 functions public API in the stable branch (3.x)
that would help me be able do some fancy things in Builder/Dazzle (which
I can make work fine on Xorg already).

If there are objections, I'd like to hear from people so I can find a
way to make forward progress.

The functions I'd like to see made public:

  - gtk_window_set_use_subsurface()
  - gdk_window_move_to_rect()

The Gdk function is currently accessible if you're compiling Gtk since
it can access the private API vtable. Widgets like GtkMenu use this to
do positioning. It didn't make it to public API in time for 3.22, but
had we continued to do a 3.24, it seems likely that would have happened.

The gtk_window_set_use_subsurface() is basically only useful when on
Wayland, but it helps ensure that we get a subsurface for transient
popup windows. I'm open to other ways to solve the problem, like
GDK_WINDOW_SUBSURFACE, if they allow me to ensure that my window is
backed by a subsurface on Wayland.

Again, this API is available internally to Gtk so widgets like ComboBox
can use it, but if you're not a GtkWidget, you're outta luck.

Thoughts?

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

Re: Does GTK+ do automated/nightly performance regression testing?

[Christian Hergert]

On 02/05/2018 02:49 AM, Emmanuele Bassi wrote:
> GSK has a prototype of a profiling object that should be improved;
> Christian Hergert has worked on performance counters for sysprof and
> gnome-builder, so we should also look at that.

For Sysprof 3.28 we'll be installing a libsysprof-capture-2.a static
archive that you can use to write Sysprof binary capture files easily.
It supports user-defined counters in addition to call stacks.

We'd need some support in Sysprof's graphing code, but it might be nice
to display counters/marks along with callgraphs/cpu/etc.

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

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

[Christian Hergert]

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 Novell/Xamarin/Unity3d invested, quite
literally, millions of dollars on consultants to work on the OS X port
(without much interest in paying additional money to have that work
upstream'd or ported to Gtk3). Add to that the necessity to write new
bindings around G-I for Gtk♯ 3 and you can get the idea of how they see
that as risk from a business standpoint.

Ardour could never move to Gtk3 because a number of VST plugins use Gtk2
and you cannot mix both into the same process space. DAW authors will
often cite the necessity for plugins to be in process to allow for a
large number of tracks/plugins due to context switching. (This is a 
contributing factor to why many DAWs write their own UI toolkits).


As for GIMP, I think the lesson I take away is that we need to recruit 
people to go do the ports for important projects rather than expect them 
to track us. Red Hat has shown that this strategy works in both Firefox 
and LibreOffice (which are arguably the two hardest applications to port).


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

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

[Christian Hergert]

On 09/10/2017 04:27 AM, Sébastien Wilmet wrote:

If I'm not mistaken, the same problem can happen with NFS-mounted home
directories.


Some relevant blog posts and mailing list entries from the past.

 http://0pointer.net/blog/projects/locking.html
 http://0pointer.net/blog/projects/locking2.html

Very long thread...

 https://lists.freedesktop.org/archives/dbus/2010-May/012777.html

There was another post I failed to locate, that went into detail on why 
none of this stuff works. I think it was from Lennart as well.


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

Re: customized alignment in gtk text view

[Christian Hergert]

You likely have an issue with variable font sizing. Use 
gtk_text_view_set_monospace() to use a fixed width font.

Also, this mailing list is for development of gtk. Use the gtk-app-devel list 
in the future.

On June 1, 2017 6:10:37 AM PDT, Karan Ahuja  wrote:
>Hi
>
>I wish to display 3 lines in gtk textview as below
>
>software-lumapix  +2000
>software-adigiprints  +3000
>software-yst  +3000
>
>on command line i see the strings as above as required.
>but when i copy the output from commandline to gtk text view or gmail
>here
>or use
>set_text method on the text buffer - the alignment is lost and i see
>this
>
>software-lumapix  +2000
>software-adigiprints  +3000
>software-yst  +3000
>
>my simple code is as below in python gtk+
>
>str1 = '{message: <{width}}'.format(message="software-lumapix",
>width=50)
>str1 = str1+'+2000'
>print str1
>str2 = '{message: <{width}}'.format(message="software-adigiprints",
>width=50)
>str2 = str2+'+3000'
>print str2
>str3 = '{message: <{width}}'.format(message="software-yst", width=50)
>str3 = str3+'+3000'
>print str3
>self.view.get_buffer().set_text(str1+'\n'+str2+'\n'+str3)
>
>
>Please guide - how can i align the numbers right aligned.
>
>cheers,
>karan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Christian Hergert]

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 codebase will be enough, I think).


It will certainly make it easier for me to stay within my ideal line 
width for some of the longer named functions. I don't mind a change to 
Gsv, that's what I think/type already when talking about the project.


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

Re: Gtk+4.0

[Christian Hergert]

Sorry for the long post, I tried to condense it, unsuccessfully.

On 06/21/2016 07:26 AM, Peter Weber wrote:
> After five years we see now Firefox and
> LibreOffice (?) on Gtk3, and progress on Gimp and Inscape, Gtk3 was
> released in 2011. From the developers side, we will forced to choose
> between to nasty options, an already outdated stable API/ABI or a shiny new
> API/ABI, which will break fast.

In retrospect, telling everyone we are going to break things in 3.x when
we branched was not the greatest strategy. However, we have gotten a lot
of core plumbing fixed and 3.x looks a lot less like the 2.x series,
which is right out of 1998.

I've worked on a few very large gtk+ applications this millennium, and
we avoided 3.x for both stability and availability reasons. Neither of
those are much of a concern for me these days.

However, it cannot be underestimated the amount of work that moving from
2.x → 3x was. The entire ecosystem of desktop software was changing
during that time-frame and applications needed to adapt not only to new
API, but to new paradigms. Lots of abstractions have been added that
allow us to have more leeway over the original X design of event
dispatches everywhere. But if you aren't using them (and stuck with the
ancient X-style event handling in your port) you might not get 100%
expected results.

For example, a very large percentage of computers released today come
with touchscreens. Whether you like it or not, we need to support the
hardware that exists. Moving to GtkGesture was a huge step in the right
direction but ultimately changes how you write input for widgets (very
much for the better!).

Now, how about things like overlay scrollbars? Every platform uses them
by default now, and implementing them required changing our drawing
model a bit and some size-request machinery. How about the people that
rely on those scrollbar troughs to draw marks on-top? If we have
"opt-in" nobody will use it correctly. If we have "opt-out" nobody will
use it at all but would remain "ABI stable" in the semantic sense.

Going forward we have even more ambitious goals. We'd like to see
GtkContainer, as it exists today, become obsolete. GtkWidgets will be
able to have children (and internal CSS Gadgets were step 1). No longer
will we need to implement widgets like GtkEntry with custom drawing, we
can simply have composition of widgets.

Even more radically, we need to change the drawing model from one based
on immediate mode rendering to something that is more easily implemented
with GPUs. This necessitates removing things like cairo drawing in the
normative case. If we always render the UI with cairo, we have to do
full texture uploads on every frame. Clearly this will not do. (For
those about to suggest cairo-gl we tried that in the last decade and no,
it's not a good idea). Some of this can be implemented in 3.x (which is
happening now), but has the potential for unforeseen side-effects.

We should be able to remove cairo from the normative case and preserve
immediate mode rendering for those that require it (or fallback). It
could also allow those who wish to use other drawing libraries like skia
to do so independently of gtk+.

Version numbering aside, we want to enable application authors to
release software that has been tested to work correctly. (As opposed to
"untested" with the current model). This is possibly the best way to
move forward, however flatpak is another excellent way to do so.

My current concern is more about theme authors. Let me start by saying I
think the result is a zero-sum game, but this will require new work by
theme authors. On one side it will be easier to know a theme works
correctly (and will be stable). On the other side theme authors will
need to write more theme variants.

-- Christian


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

Re: Developing a new text editor widget?

[Christian Hergert]

On 06/11/2016 02:47 AM, Sébastien Wilmet wrote:
> /tmp is mounted in RAM on some distros, AFAIK. Maybe a better place is
> ~/.cache/, so opening a 8GB file is feasible (not sure it is useful
> though, but people coming from Windows expect to be able to use a GUI
> tool for everything).

Sure. O_TMPFILE/unlink() is just handy to avoid leaking filenames.

> In French there is æ and œ, those should ideally be displayed as 1.5x
> the size of a char. Or there is also "…". But those are still entirely
> readable in monospace. But I think in other languages, there are
> characters that should take 2x the size of a cell.

As long as we can treat them as non-fractional boundaries then this is
fine. If not, it just affects the column index, not the line index and
somewhat complicates the "what column am I on" question.

> When loading a large file (e.g. 20 MB), we indeed see GtkTextView busy
> computing its size. But for a file of 10k lines, there is absolutely no
> problem.

This is not true. If it were, I would be able to open gtktextview.c and
scroll to the bottom immediately upon restoring cursor position like I
can in vim.

You are left with either jittered scrolling (when you come across more
complex portions of text the layout/draw cost is greater) or you decide
to stall until the calculation is far enough that you can animate there
smoothly.

> When I was a heavy user of gedit a few years ago (for developing in
> Vala), I've never seen the scrolling performances as a problem.

Then you had too small of resolution for it to be an issue. It's barely
keeping up at 2560x1440 at 1x and even worse at 2x with QHD. The
scrolling performance is incredibly timing sensitive. If you have more
complex blocks of text, it gets worse. Being off by a ¼ of a millisecond
still results in a dropped frame which is jarring.

This is exacerbated by the laziness in the pixelcache design. When we
have a damage or require a full draw (happened *a lot* until the recent
GSV changes I put in place) we need to draw roughly 2x the visible area
and all within the time period that the FrameClock normally saw for our
normative drawing cost (ie: memcpy). Anything we do to improve this
design (instead of replace) will likely result in predicting draws
sooner to ensure the FrameClock schedules additional time for drawing.

-- Christian

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

Re: Developing a new text editor widget?

[Christian Hergert]

On 06/05/2016 01:25 PM, LRN wrote:
>> If we could sacrifice 100% correct scrollbar correctness (really,
>> its
>>> not that big of a deal) we could avoid this problem. Just
>>> estimate by byte offset the Y position, and make calculated
>>> offsets in the Y position b-tree/treap/index relative to it's
>>> parent node.
> That could be an interesting feature. Places with dense code (many 
> characters, compared to the number of '\n's) will take longer to
> scroll through (if each PageDown scrolls N bytes).

That should be fine. The issue is more about when you jump to 75% of
the document from the top.

We can calculate local sizing information while skipping the
line-height calculation of 0..75%.

-- Christian

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

Re: Developing a new text editor widget?

[Christian Hergert]

On 06/05/2016 10:35 AM, Sébastien Wilmet wrote:
> It would indeed be really nice to have such an implementation, to
> support very large files and very long lines (GtkTextView currently
> doesn't support well very long lines, there is a performance issue). But
> writing a new text widget is a major undertaking. For example, just for
> the mmap idea, is it possible to mmap a remote file? (that's a real
> question, I actually have never tried). And what about encoding
> conversion if the file isn't UTF-8?

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() is simply an optimization over a page/extent read.

You need to iconv/etc the whole thing sequentially and therefore must
read in the whole file upfront. However, you can do this and then
proceed as normal with the alternate file afterwards (using O_TMPFILE or
tmpfs backed fd).

> There was also some talks about a monospace-only textview. But even in
> source code, a string or comment can contain text in any language. So
> having good i18n support as an option can be a big advantage when
> choosing a text widget or toolkit.

Are there situations where the character is larger than a single cell?
Do we want to support widgets interleaved with characters? I know I'd
like widgets *between* lines, but not sure I want widgets between
characters/words on a line.

LTR/RTL is one thing, but that can still exist while being monospace.
The important performance gain we want is to make the operation of
converting line,column → x,y as close to O(1) as possible. We likely
still need an index for line positioning though, because I'd like to be
able to insert widgets in-between lines. (Imagine showing IDE fixits as
a list of items underneath the line they fix).

We definitely want both an line and a column index going forward though.

> For source code, GtkTextView is really not that bad IMHO. Normally
> source code doesn't trigger the very long line problem (and even, this
> problem in GtkTextView is fixable by internal refactorings, although
> nobody tried recently AFAIK). And source code is contained only in very
> small files, it is not a problem to load e.g. 20k lines in memory.

There are a few things that it is really bad at.

You have to scan linearly from O..n to determine line height. There are
all sorts of hacks to do this upfront in high-priority idles. It's why I
still can't open a file, and scroll to a line number like 1000 correctly
without retrying a bunch of times.

If we could sacrifice 100% correct scrollbar correctness (really, its
not that big of a deal) we could avoid this problem. Just estimate by
byte offset the Y position, and make calculated offsets in the Y
position b-tree/treap/index relative to it's parent node.

> And if a new text widget is written, there is the question about the
> API. If the API is different, porting all the applications to it would
> also be a huge amount of work. The GtkTextView API is not that bad, I
> find it convenient to use, even if it could be modernized or improved
> here and there (leverage CSS, better support multiple views, and a few
> smaller things). So, if one day a new text widget is written, I think it
> would be a good idea to not diverge too much from the GtkTextView API.

Mostly agree, but I wouldn't be willing to lock myself into an API
choice until the problem is solved.

As you said at the start, this is a massive undertaking. While I have
ideas on how to implement this, I need to be realistic with my time and
I have a lot of work in front of me right now.

The main thing I'd like to learn at the hackfest is what constraints
must we take on to do fast text scrolling with GSK+(GL/Vulkan/etc). This
pixelcache copying on every frame is really hard to optimize.

-- Christian

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

Re: G_UTF8String: Boxed Type Proposal

[Christian Hergert]

On 03/19/2016 02:04 PM, Randall Sawyer wrote:
>> It's possible you are focusing on implementation before measuring the
>> problem. DRY alone is not a sufficient argument.
> 
> "DRY" is not a term I know - or at least in the way you are using it
> here.

https://en.wikipedia.org/wiki/Don't_repeat_yourself

> 2) Tags for text containing the digits and cardinal directions
> specified as editable. Tags containing other symbols - uneditable.

I suspect with all the new CSS work this could be implemented as a
series of entries without frames and a box drawing the entry frame.

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

Re: G_UTF8String: Boxed Type Proposal

[Christian Hergert]

On 03/19/2016 12:25 PM, Randall Sawyer wrote:
> 
> If there already were such a structure, then it could already have been
> employed by existing objects and structures such as GtkEntryBuffer and
> PangoLayout - to name two - eliminating the need for extra lines of
> redundant code. In fact - as I envision it - the entirety of struct
> _GtkEntryBuffer IS a GUString - and all of the procedures which operate
> upon instances of that structure could be performed by g_ustring_*()
> functions!

It's possible you are focusing on implementation before measuring the
problem. DRY alone is not a sufficient argument.

> The emergence of such a structure may, IMHO, facilitate more rapid
> development of future structures and objects which could also benefit
> from having such a length-aware string object. That's all.

One topic I'm interested in covering at the hackfest in June (if there
is sufficient interest) is a general purpose text buffer for Gio.

While not a particular goal, it would allow us to pass content between
gtk and pango without requiring contiguous strings. But that is an awful
lot of pango work and Behdad is probably in the best situation to say if
it would even help. I suspect on *really* long lines it might, but
otherwise not.

Some notable things I want to make a modern textview:

 1) Interface that makes it possible to mmap() source contents
and/or a page cache for large file support. Being limited to
virtual address space like we are today is non-ideal.
(SQL dumps, log viewers, IRC backlog come to mind).
- another interface implementation could be a contiguous string,
  but i expect the same append only structure is still faster
  once you start editing.
 2) Interface implementations that use append only change buffers.
 3) Unlimited Undo/Redo tracking
 4) Ability to get a snapshot of the buffer for off-thread processing.
(Highlighting, glyph sizing, etc).
a. ability to do this without doing copies in most cases
 5) Ability to attach indexes to "GTextBuffer"
a. Number of code points could be one such line-based index
b. Line height calculations another
c. highlighting tags, completion word indexes, etc
d. index merging to merge off-thread calculations
e. This gets a little tricky when you want multiple views with
   different font sizes (like we do in Builder and Gedit)
 6) efficient slices for copy/paste

One thing you'll notice when you combine the above is that you've
basically written a database.

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

Re: G_UTF8String: Boxed Type Proposal

[Christian Hergert]

On 03/19/2016 06:57 AM, Randall Sawyer wrote:
> 
> Some object classes - such as GtkEntryBuffer - store this value and
> update it as text is inserted or deleted. That is efficient. The fact
> that developers need to write equivalent code for each such class is
> inefficient.

A string abstraction like the one you describe is not an efficient way
to do text processing, especially for interactive widgets.

It's much better to split things into two data-structures.

1) An append only buffer with all text content.
2) A pointer table with start:end tuples representing ranges in the
append only buffer.

And if you are doing a full text editing widget like GtkTextView:

3) Other necessary indexes are similar to #2, with interval trees. (Line
height, row calculations, format tags, etc)

This simplifies unlimited undo, mmap()'ing large input data, avoiding
large memmove()s and simplifying incremental utf-8 validations.

Before we add new data structures to GLib, we like to have a solid use
case for which the data structure solves. So far, I haven't seen a
concrete problem for which this data structure would be the ideal fix.

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

Re: GTK+ hackfest 2016

[Christian Hergert]

On 03/07/2016 02:03 PM, Behdad Esfahbod wrote:
> 
> Any idea why the page says Immutable to me?
> 
>   https://wiki.gnome.org/Hackfests/GTK2016
> 
> I remember having seen this before but don't remember what the
> resolution was.

There was some spam related issues I believe.

I've added you to the TrustedEditors group on:

  https://wiki.gnome.org/TrustedEditorGroup

Should no longer be immutable for you.

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

Re: Gio.Menu item with data ?

[Christian Hergert]

Hi,

On 12/05/2015 06:06 AM, Stuart Axon wrote:
> Hi,
>I'm going a bit mad trying to find decent examples - I want to have a
> bit of data attached to a menu item, how can I do it ?
> (my action is something like win.open_example + I want to have a
> filename attached to each item).
> - I can't find anything with SimpleAction so far.

You want to make a single action that takes a parameter, in this case,
your filename (or rather, a string URI).

static void
on_open_file (GSimpleAction *action,
  GVariant  *param,
  gpointer   user_data)
{
  const gchar *uri = g_variant_get_string (param);
  GFile *file = g_file_new_for_uri (uri);

  // ...
}

static const GActionEntry entries[] = {
  { "open-file", on_open_file, "s" },
};

and then where you call the action, use the detailed action name or
specify a target like:

  g_menu_item_set_action_and_target (menu_item, "prefix.open-file",
 "s", uri);

If you'd like a similar, rather complex example, check out how we open
files based on mime-types in Builder.

 
https://git.gnome.org/browse/gnome-builder/tree/plugins/project-tree/gb-project-tree-builder.c?h=wip/chergert/perspective#n223
 
https://git.gnome.org/browse/gnome-builder/tree/plugins/project-tree/gb-project-tree-actions.c?h=wip/chergert/perspective#n152

Hope that helps,

-- Christian

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

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Christian Hergert]

On 10/15/2015 07:19 AM, cee1 wrote:
>> From GStreamer point of view, the main problem as it was explained to
>> > me, is the global locks, creating contention (GStreamer is highly multi
>> > -threaded). It's also a base type reserved for very specific use cases
>> > (where a lot of that type need to be allocated, GstBuffer, GstEvent,
>> > etc.). I'm not sure it make much sense generically. Specially that you
>> > loose most of the feature of an object, properties, interface, signal,
>> > etc.
>
> Such mini objects may also play a role in GTK+, I guess...

Almost certainly not. Gtk uses properties and signals heavily, and is
dominated by single threaded operations. Basically the complete opposite
of why GstMiniObject was created.

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

Re: Custom TextBuffer

[Christian Hergert]

On 08/29/2015 09:22 PM, Rena wrote:
 This information is generated on the fly and would span millions of
 lines that the user can page through.

Keep in mind that a non-pageable b-tree is used to track various
information about the text so the view has fast access to it.

I don't think GtkTextBuffer can do what you want as a subclass, nor will
it gracefully handle unbound input length. GtkTextIter returns an int
for character offset, so you are at least restricted to 31-bit
addressing (read: 2Gb).

I'd start by trying to open a 1Gb file. That is going to be the trivial
case of your dynamic text generation. If it can't handle that well, then
even if the buffer could dynamically generate content, the view won't
keep up. Keep in mind it needs to size all the text rows so that it can
know about line heights and how big the rendered content would be. (It
does this lazily, but still).

You might want to look at how Vte does it's scrollback. If you don't
need any sort of syntax highlighting or exotic pango layouts or word
wrapping, you might be able to do your own thing. It will be a lot
simpler code if all the line heights are the same anyway.

Good Luck,

-- Christian

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

Re: g_error_free() warning on null pointer

[Christian Hergert]

Hi,

On 08/15/2015 02:54 PM, Michael McConville wrote:
 Rather than strange, I'd say it was intentional and insightful. In
 function bodies, you often have pointers that are used in conditions and
 may or may not be null. There's a very easy and clean way to deal with
 this: initialize them to NULL at the beginning and free them at the end.
 Freeing conditionally in the body can be awkward and often leads to
 memory leaks. I can send you a few examples from the Pidgin codebase if
 you're interested.

Try g_clear_error(error) instead of g_error_free(error) to get the
effect you want.

If you have a modern compiler/GLib, you can use g_autoptr() as well. I
usually avoid this with GError though, in case it gets used in multiple
paths.

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

Re: CSS and style-properties on master

[Christian Hergert]

On 04/20/2015 12:52 PM, Christian Hergert wrote:
 https://git.gnome.org/browse/gnome-builder/tree/data/keybindings/vim.css

This commit seems to fix things in Builder.

  https://git.gnome.org/browse/gnome-builder/commit/?id=629a385

It should have been that way to begin with, but it does suggest that
maybe the cache isn't being invalidated.

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

CSS and style-properties on master

[Christian Hergert]

Builder has a complex Vim and emacs keybinding implementation which
relies on GtkWidget style-properties being configurable from CSS. We
need this because we manage a state-machine using CSS selectors and
transitioning between them in a keybindings agnostic way requires a
bit of additional information.

This has broken on gtk+ master (since CSS node work). It renders many,
many, many hours of implementing this in the last couple of months unusable.

For now, working and developing Builder requires that we continue to use
the 3.16 branch.

Is there any chance these are coming back? Do I need to go about finding
a new way to implement this? Doing the Vim implementation in CSS has
been a lot easier to manage than custom keybinding modes written in C. I
really would prefer to keep the implementation this way.

https://git.gnome.org/browse/gnome-builder/tree/data/keybindings/vim.css

At least with Builder, this type of break is manageable since we move in
lockstep with Gtk+/GNOME.

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

Re: Should we drop XP?

[Christian Hergert]

On 04/01/2015 12:47 AM, Alexander Larsson wrote:

On ons, 2015-04-01 at 09:46 +0200, Ignacio Casal Quinteiro wrote:

well one of the reasons is that we are patching downstream in this
ways (it can be fixed though)
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-glib2/0027-no_sys_if_nametoindex.patch


and afaik fan or lrn had some ideas to improve some parts of the code
once xp is dropped


Sounds like its time to drop it then!


I know this is *slightly* off topic, but can we consider dropping GSlice 
too? Last I asked around it sounded like it was required on Windows for 
older systems that had an atrocious malloc implementation.


On a modern GNU/Linux, glibc's malloc uses both less memory than GSlice 
and is significantly faster (and doesn't screw up gdb). I did a bunch of 
benchmarks[1] on this last year at the Berlin hackfest.


I'd love to hear from the GStreamer folks on all of this anyway, since I 
believe they are likely the heaviest user of GLib+win32.


-- Christian

[1] https://github.com/chergert/alloctest
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: I'm done with O_CLOEXEC

[Christian Hergert]

On 03/20/2015 01:43 PM, Ryan Lortie wrote:

karaj,

For those unfamiliar with the issue: when a process is created on UNIX
via naive fork() and exec(), the default is that the process will
inherit all of the file descriptors of the parent.  This makes a lot of
sense for stdin, stdout and stderr, but almost nothing else.

This has been the cause of a lot of strange problems over the years.
The typical example: a process will open a listener socket at some point
and sometime later will call a library function that does a naive
fork()/exec() of a helper process that hangs around past the lifetime of
the original program.  When you try to restart the first program, the
socket is still being held open by the helper and the new instance can't
bind it again.

There are two fixes to this problem.


[..snip..]

This makes me happy. I don't think I've actually seen any of this stuff 
handled right. Not to mention that close() itself is basically broken in 
multi-threaded scenarios on Linux (Linus says to basically just not 
worry about it if you get EINTR, which may or may not have succeeded, 
and then the FD entry taken by another thread).


What I would welcome, is a function that says glib, close all FDs you 
know about or that you created. If all the libraries did that, at least 
it would be possible for applications to maybe, sorta, do the right 
thing. (That would push the synchronization responsibility during 
fork()/exec() to the application).


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

Re: File monitor rewrite: Solaris (and other) help wanted

[Christian Hergert]

On 01/14/2015 02:00 PM, Ryan Lortie wrote:
 I'm making substantial modifications to the file monitoring system in
 GIO.  I've gotten to the point where I feel comfortable pushing a branch
 that contains the main ideas:
 
   https://git.gnome.org/browse/glib/log/?h=wip/mount-watcher
 
 It's not even vaguely tested or stable and will probably crash under
 anything more than the most trivial of uses.  Work will continue over
 the next days.
 
 The private API between GIO and the internal file monitor backends has
 changed substantially.  See the commit message for details about that. 
 This means that all of the backends will need non-trivial changes.  I've
 already made the required modifications to the inotify backend.  I plan
 to move next to the kqueue backend and I could probably even tackle the
 FAM and win32 backends myself.
 
 I have no means of testing changes to the 'fen' backend (Solaris).
 
 It would be awesome if someone with a Solaris box and some free time
 could port the fen backend to the new changes.  If nobody comes forward,
 we will probably remove the backend.

I quickly read over the relevant commit message. I didn't see anything
alluding to the goal of the patch set. I'm sure there is a goal you have
in mind?

Overhead reduction, performance related I assume?

-- Christian

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

Re: [PATCH] GtkTextView: allow to extend selection with mouse scrollwheel

[Christian Hergert]

On 01/09/2015 04:25 PM, Nelson Benítez León wrote:
 I would like to ask review for the following patch that it's been
 in bugzilla for more than a year[1] waiting for review:
 
 https://bugzilla.gnome.org/show_bug.cgi?id=710612
 
 It's about making GtkTextView able to extend the text selection with the
 mouse scrollwheel, which is currently not possible.

Seems to work well to me. Perhaps someone else can ack the patch though.

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

Re: a new combo box

[Christian Hergert]

On 12/27/2014 07:50 AM, 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 ?

Can I style combobox items with CSS?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Christian Hergert]

On 12/27/2014 01:44 PM, Morten Welinder wrote:
 Can we keep the api -- function names, etc.?
 
 I.e., could we, for once, do such an upgrade without inflicting
 pain on the users?  Even at the cost of some pain for
 developers.

On the other hand, this is the type of thing where people also complain
that we break ABI because it doesn't work/look the same as before.

So my vote is opposite. Don't make it compatible unless it is
functionally the same.

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

Re: Improve word boundaries for text widgets

[Christian Hergert]

On 09/27/2014 04:52 AM, Sébastien Wilmet 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 choose 'w' instead of 'e'? I think 'e' and 'b'
 are better for word selection with Ctrl+Shift+arrow.

I just want to have a small VIM compatibility layer for some of us that
can't change our mental model to a non-modal editor. I'm not totally
sure I'll go through with this fully, but it's worth spending a day or
two prototyping on top of GtkTextView/GtkSourceView.

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

Re: Improve word boundaries for text widgets

[Christian Hergert]

On 09/26/2014 06:13 AM, Sébastien Wilmet wrote:
 I would like to improve the word boundaries for the text widgets:
 GtkTextView, GtkEntry and GtkLabel (anything else?). More precisely the
 word boundaries used for word movements (Ctrl+arrow) and word selection
 (double click). Currently the behavior is not consistent across the text
 widgets in GTK+ (and other applications), and the current word
 boundaries don't work well with spaces, punctuations,
 variables_with_underscores, etc.

Awesome!

 By seeing how Vim handles word movements, I think it's a much better
 behavior. Deriving the Vim word boundaries from the Pango word
 boundaries is quite straightforward (I have a workable patch): it uses
 only the is_word_start and is_word_end PangoLogAttr attributes,
 g_unichar_isspace() and compare if a character is an underscore.

I'm doing exactly this in Builder today for VIM style `w` and `b`.

 Another idea for GtkTextView is to add a vfunc to let GtkSourceView
 define custom word boundaries for word movements and selection. But
 all what GtkSourceView would do is to define the Vim word boundaries,
 which are generic. The Vim word boundaries are good enough, we don't
 need more flexibility. So I prefer to implement directly the Vim word
 boundaries in GTK+, and have a consistent behavior with other widgets.

I would really like this to be a vfunc so that it could be handled by
per-language overrides in GtkSourceView/GtkSourceLanguage.

Additionally, I'd like double-click and triple-click to be different
things. Imagine triple-click selecting the whole scope in some C code
for example.

 Do you think it's a good plan?

I can't speak for everyone, but clearly useful for me on Builder.

-- Christian


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

Re: Does gobject-introspection support the cross-compile?

[Christian Hergert]

There were some prototypes for Yocto that did this by running the
introspection programs inside of Qemu.

Not sure on the status though.

-- Christian


On 08/12/2014 10:31 PM, Tristan Van Berkom wrote:
 On Wed, 2014-08-13 at 09:09 +0800, Rongqing Li wrote:
 Hi:

 I want to compile gobject-introspection for arm cpu in x86 host,
 both are linux OS. The compilation failed since g-ir-compiler
 (compiled for arm) can not run on x86.

 Could you tell me if it supports the cross-compile, if not, what
 should I do to enable it? is it possible that I use the host's
 g-ir-compiler/g-ir-scanner to compiler the target(arm cpu) file.
 
 This sounds like a typical problem you will run into when cross
 compiling your stack, pkg-config is another example.
 
 There are probably a number of techniques you can use, and one
 option to consider is to just actually build on the target
 arch. If you must cross-compile, one project which I've
 used with success is buildroot[0], this solves the said problem
 by building two stacks, one 'staging' stack which contains
 tools compiled for the build host arch, and then the target
 stack which is cross compiled, executing binaries from the
 'staging' build directory.
 
 Cheers,
 -Tristan
 
 PS: fwiw there is also a new gobject-introspection mailing list:
 https://mail.gnome.org/mailman/listinfo/gir-devel-list
 
 [0]:http://buildroot.uclibc.org/
 


 -Roy


 | ./g-ir-compiler: line 117: 
 /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/build/.libs/lt-g-ir-compiler:
  
 cannot execute binary file: Exec format error
 | ./g-ir-compiler: line 117: 
 /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/build/.libs/lt-g-ir-compiler:
  
 Success
 | make[2]: *** [gir/xfixes-4.0.typelib] Error 126
 | ./g-ir-compiler: line 117: 
 /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/build/.libs/lt-g-ir-compiler:
  
 cannot execute binary file: Exec format error
 | ./g-ir-compiler: line 117: 
 /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/build/.libs/lt-g-ir-compiler:
  
 Success
 | make[2]: *** [gir/xlib-2.0.typelib] Error 126
 | Traceback (most recent call last):
 |   File ./g-ir-scanner, line 44, in module
 | from giscanner.scannermain import scanner_main
 |   File 
 /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/gobject-introspection-1.40.0/giscanner/scannermain.py,
  
 line 35, in module
 | from giscanner.dumper import compile_introspection_binary
 |   File 
 /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/gobject-introspection-1.40.0/giscanner/dumper.py,
  
 line 28, in module
 | from .gdumpparser import IntrospectionBinary
 |   File 
 /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/gobject-introspection-1.40.0/giscanner/gdumpparser.py,
  
 line 31, in module
 | from .transformer import TransformerException
 |   File 
 /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/gobject-introspection-1.40.0/giscanner/transformer.py,
  
 line 27, in module
 | from .girparser import GIRParser
 ___
 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
 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: A Gtk's build system ?

[Christian Hergert]

Sounds like we have some people willing to port the build system to waf!

But seriously, without seeing what it would look like on another system,
this thread can't go much further. Autotools is what it is, and Gtk+ is
one of the most portable pieces of software in our ecosystem.

Making sure that waf runs properly on all of the target systems is going
to take some upfront work. Just because it uses Python doesn't mean it's
portable. Plenty of Python API's return different values based on the
host operating system.

-- Christian


On 08/06/2014 01:01 PM, Krzysztof Kosiński wrote:
 2014-08-06 21:43 GMT+02:00 Colomban Wendling lists@herbesfolles.org:
 Le 06/08/2014 21:30, Krzysztof Kosiński a écrit :
 [Waf] does not require silly lists of files to work

 If that refers to using globs in the build system files, don't.  Glob
 showed on many a situation to be the source of various build problems,
 including, but not limited to, a file to be missing from the source tree
 (which would not be easily noticeable and would work on the author's
 setup), or unexpected files to be included in a build.
 
 I am not really convinced by this.
 
 1. If there are any uncommitted files, version control will tell you about 
 this.
 2. If you have 'unexpected files' in the source tree, you are doing
 something wrong.
 3. Another common argument in favor of file lists is determining what
 to include in the tarball. This is only an issue because by default
 Autotools create a giant mess by putting generated files in the same
 directories as the sources (CMake does this as well). Waf always puts
 all generated files in a separate directory, so everything that's not
 in the build directory should be distributed.
 
 Also, FWIW patterns can generally be used just fine in Autotools -- but
 again, please, don't use them.
 
 Autotools can't correctly use patterns / wildcards, because it
 requires manually re-running automake whenever a file is added or
 deleted.
 http://www.gnu.org/software/automake/manual/html_node/Wildcards.html
 Waf stores a database of files seen on last build and therefore
 doesn't suffer from this problem.
 
 Regards, Krzysztof
 ___
 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: libsoup + gsettings-desktop-schemas for server code

[Christian Hergert]

On 03/03/2014 06:40 AM, Colin Walters wrote:


How about this as a strawman:

1) Split off some of the core settings like org.gnome.system.proxy into
gsettings-core-settings or something
2) Have a common keyfile in /etc/gsettings-core.conf that headless
server code can use


+1 from me. I have a bunch of libsoup based servers and that is a rather 
sore point.


-- Christian

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

Re: share an excitement about Gnome

[Christian Hergert]

On 10/15/2013 06:23 AM, Hashem Nasarat wrote:

You may be interested inhttps://github.com/chergert/gnome-builder


Hi,

I'm working on this. (But I broke a lot of stuff on the airplane back 
from Montreal last night). I'm doing some major restructuring right now 
based on current plans. It will move to git.gnome.org in the 
not-to-distant future.


Cheers,

-- Christian

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

Re: Spell checking in GIO

[Christian Hergert]

On 10/07/2013 09:36 PM, A. Walton wrote:
My only question is why GIO and not GDK? This kind of per-platform API 
would happily reside in GDK and prevent us from adding even more 
extension points to GIO. There's really nothing I/Oish about this API 
(despite GIO already being the home for lost GObjects since there's no 
GDesktop library between Glib and GTK+), and I can't think of any 
obvious applications that would want spell checking and not want GTK+.


Is there a good reason for spell checking to be this low in the stack?


There are certainly cases such as Clutter applications that need not 
rely on Gdk.


Additionally, it could be used for something like Search in GNOME Shell. 
First run the search text through spell check and search the corpus 
against all possible suggestions to catch things like friefox.


-- Christian

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

Re: The new GTask name in GIO is wrong

[Christian Hergert]

On 11/02/2012 07:15 AM, Tal Hadad wrote:
 First, there were an old project called GTask[0], which tried to give
 parallelism ability and
 alternative to today GIO async(I think it wasn't exist back than).
 At first, I thought, what? Gtask has been merged with GIO

I wrote GTask (and Iris), and I was wrong to call it that :-)

I do hope that someday we have task decomposition for doing neat things
with parallel for and callback chains (and you will find such
information in the bug report).

-- Christian


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

Re: Infinite List

[Christian Hergert]

On 09/13/2012 09:34 AM, Nick Glynn wrote:
 I'm writing an app that shows information from a website - a similar app
 to Pattrn for Android but for Gnome- but don't want to have all
 data/images downloaded and present before the app starts.
 
 What's the best widget/method to implement an Infinite List[1] style
 mechanism using Gtk where more data requests are fired either by a
 reload gesture/button or, preferably, by exposing the bottom of the list?

So there are a couple separate problems to deal with here. And depending
on the potential worst case you want to handle, there are different ways
of doing it.

One problem, is how do you want to store the content for all of those
items. Do you plan on doing that in memory? Do you want it in a local
database that gets queried per row?

If you want to handle it in memory, use a GtkListStore. You can have a
column that indicates this is the last row, and use a
GtkCellRendererDataFunc to prepare the GtkCellRenderer appropriately.

On the GtkTreeViews row-activated signal, you can check if it is your
special row and fetch new data. Then append it to the list (or simply
insert right before your load more data row).

However, if relatively constant memory overhead is important and you are
working with millions of rows, then I would suggest a different UI
design :-)

FWIW, I think a tutorial for this pattern is a good idea. You aren't the
first, and won't be the last to ask this.

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

Double Buffer extension on X11

[Christian Hergert]

Hi,

I was hoping that this topic was beaten to death, but I haven't been
able to find any discussion on the topic. I'm not very knowledgeable on
the extension (yet), so if you have valuable information on the topic,
please share it!

Is there a reason that gtk+ doesn't use the DOUBLE-BUFFER extension on
X11? Does the current design of composting negate it's usefulness? Is it
that nobody has stepped up to implement it? Is the DOUBLE-BUFFER
extension broken in ways that make it worse than the double buffering
provided by gdk directly? Does the XdbeBufferSwap() belong in cairo more
than gdk?

Anyway, I'm just trying to find out if spending some time trying to
implement this is a complete wast of time for reasons already known.

Thanks!

-- Christian

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

Re: roadmap for 3.6

[Christian Hergert]

On Sat, 2012-08-04 at 21:44 -0700, Andy Tai wrote:
 Maybe not directly related, but will gtjk+ gain the animation
 capabilities of Clutter (via merging with Clutter or layering on top
 of Clutter), such that gtk+ widgets can behave like Clutter actors?

I wrote something like this for animating GObject's in general. So it
doesn't take advantage of clutter or anything.

It isn't ideal since you potentially damange a lot of window area as
properties change (causing graphics stalls or frame dropping), but if
used sparingly it can work. I find it handy for animating changes in
adjustments, progress bars, and such.

See ppg-animation.{c,h} for the details.

https://github.com/chergert/custom-gtk-widgets/tree/master/animated-grid

-- Christian


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

Re: RFC: new features

[Christian Hergert]

On Wed, 2012-01-18 at 09:49 +0100, Sergio Villar Senin wrote:
 En 13/01/12 16:04, Bastien Nocera escribiu:
  On Thu, 2012-01-12 at 11:23 +0100, Alexander Larsson wrote:
  On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote:
  snip
  MENU BUTTON
  A GtkButton that shows a menu when clicked (and handles positioning,
  etc). Some would just use a combobox, but I find them pretty different.
  You'll find this sort of menu button in various VMware products on
  Linux. (I know the fullscreen toolbar used to have it at least).
 
  Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to
  do but would be nice to have in a single place. Also, it needs some help
  from the theme to look good, like adwaita does here:
  http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705
 
  Totem has a menu button as well, look for popup_button in:
  http://git.gnome.org/browse/totem/tree/browser-plugin/totem-plugin-viewer.c
 
 Epyphany hackers have also recently added the super menu which is a 
 similar concept.

Would anyone like to propose an API for how this should be implemented
in Gtk? My assumption is just that we need a menu property and a menu
position func with default implementation. Anything else?

-- Christian

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

Re: RFC: new features

[Christian Hergert]

On Wed, 2012-01-18 at 09:47 +0100, Alexander Larsson wrote:
 On Mon, 2012-01-16 at 13:08 +, Bastien Nocera wrote:
  On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote:
   Hopefully this isn't getting old, but I'm sort of just throwing these
   out there as I think of them.
   
  snip
   BACKGROUND OPACITY
   It would be nice to have the ability to alter the opacity of a window
   without altering the opacity of GdkWindow'd widgets inside it. This is
   useful for utility windows that float over a primary window. Right now,
   you have to handle changes with the visual and/or screen and modify the
   background yourself. This breaks possible theming and is tedious.
   http://www.pixelmator.com/ is a good example of why this might be
   useful.
  
  Had that problem in the Wacom calibration screen. I wanted the elements
  to be opaque but on a translucent dark background. It wasn't possible
  without resorting to hacks (such as having 2 windows, one translucent
  with the black background, one with the opaque elements on a transparent
  background).
 
 Can't you just make the window an RGBA window with a semi-transparent
 color on the toplevel, but normal bg colors on the other widgets?

That sounds about right. If I understand the problem correctly, you have
to make sure the visual supports RGBA and then update the GdkRGBA on
style changes. My argument was that it would be nice if this was done
for us with a background-opacity property between 0.0 and 1.0.

-- Christian

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

Re: RFC: new features

[Christian Hergert]

On Mon, 2012-01-16 at 13:08 +, Bastien Nocera wrote:
 On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote:
  Hopefully this isn't getting old, but I'm sort of just throwing these
  out there as I think of them.
  
 snip
  BACKGROUND OPACITY
  It would be nice to have the ability to alter the opacity of a window
  without altering the opacity of GdkWindow'd widgets inside it. This is
  useful for utility windows that float over a primary window. Right now,
  you have to handle changes with the visual and/or screen and modify the
  background yourself. This breaks possible theming and is tedious.
  http://www.pixelmator.com/ is a good example of why this might be
  useful.
 
 Had that problem in the Wacom calibration screen. I wanted the elements
 to be opaque but on a translucent dark background. It wasn't possible
 without resorting to hacks (such as having 2 windows, one translucent
 with the black background, one with the opaque elements on a transparent
 background).
 
 Do you mind filing a bug about that?

Filed as https://bugzilla.gnome.org/show_bug.cgi?id=668063

-- Christian

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

Re: RFC: new features

[Christian Hergert]

On Fri, 2012-01-13 at 21:51 +, Alberto Ruiz wrote:
 I think that if we were up to do this, we should go ahead and get rid
 of GtkTreeModel altogether and substitute it for something like
 libmodel.

As long as it's not libmodel, or anything that requires encapsulating
the value inside a GObject. (e.g. ModelString, ModelFloat, ModelInteger,
ModelBoolean).

-- Christian

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

Re: RFC: new features

[Christian Hergert]

On Fri, 2012-01-13 at 17:21 -0500, Paul Davis wrote:
 On Fri, Jan 13, 2012 at 4:51 PM, Alberto Ruiz ar...@gnome.org wrote:
  I think that if we were up to do this, we should go ahead and get rid of
  GtkTreeModel altogether and substitute it for something like libmodel.
 
  The data driven app situation in GObject/Gtk+ is quite sad at the moment and
  there's a lot of code that could be reused (like data/search filtering and
  data model backends) if we had a proper collection/data model API in place
  and used by the toolkit.
 
 there is a bigger issue there, i think. in an ideal world, you don't
 want to base the date store for the TreeView on an object, but on an
 interface.  then you want a series of adapters/wrappers that wrap data
 structures implemented in any language (or any language with a GTK
 binding) with the required interface. some of which might be null
 adapters that just do passthrough to the underlying data object.
 
 there's nothing more stupid that taking a native data structure
 (e.g. a C++ list, a python array, some app-specific creation, etc) and
 having to copy the data out of it into some GObject-based data
 structure before being able to give it to the TreeView. well, ok,
 there are lot of things that are a lot more stupid than that, but its
 still pretty aggravating. yes, i understand that GTK sits atop GObject
 in some fairly fundamental ways, but the TreeView is about displaying
 application data, not GTK state, and a much simpler mechanism for
 allowing the use of the data structures already in place in an app
 would be super-welcome.

Additionally, if we were to go down this path, having the ability to
have sections would be lovely. The way this seems to get done now is
with dummy rows that get styled differently by the cell renderers and
extra work to avoid selections. This means that you have little to no
consistency between applications. Also, it should be styled by the css
themes.

Essentially, something like the sections in the Nautilus sidebar.
However, it would need to scale slightly better since one might use it
to group emails by day, week, month, etc.

-- Christian

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

Re: RFC: new features

[Christian Hergert]

Hopefully this isn't getting old, but I'm sort of just throwing these
out there as I think of them.


ROUND BUTTON
This one might be a stretch, but is probably solvable with some CSS
classes that are guaranteed to be there. Sometimes you want a button
that is a circle. Buttons for a Phone Dialer or a record button might
be good examples of when to use it. Arguably, this might fall under the
not common enough category.


BACKGROUND OPACITY
It would be nice to have the ability to alter the opacity of a window
without altering the opacity of GdkWindow'd widgets inside it. This is
useful for utility windows that float over a primary window. Right now,
you have to handle changes with the visual and/or screen and modify the
background yourself. This breaks possible theming and is tedious.
http://www.pixelmator.com/ is a good example of why this might be
useful.


CELL RENDERER BOX
GtkCellAreaBox being a GtkOrientable helps for very basic things in a
GtkTreeView such as a single column like:

  Title
  [==50%  ]
  Description

But it doesn't allow for more complex layouts per line. My understanding
is that the following isn't possible using built-in objects from Gtk.

  Title   Today
  [==50%  ]
  Description

We need a GtkCellRendererBox that allows packing cells within the cell.
(Spare me the Yo, Dawg meme).


FAST/SMOOTH SCROLLING (POSSIBLY INFINITE SCROLLING)
A sort of container widget that handles keeping a couple pages to
either side of the visible region in server side pixmaps. It would
handle calling back to render various pages as needed based on
scrolling. This could be useful for preview applications like Evince,
Abiword, or slideshows. Possibly even reusable by
GtkTextView/GtkTreeView.


-- Christian

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

Re: RFC: new features

[Christian Hergert]

On Thu, 2012-01-12 at 03:59 +0100, Benjamin Otte wrote:

 PLOTS
 This is my personal pet peeve. I often have something I'd like to
 quickly plot in GTK, but it always ends up being more complicated then
 I thought, so I either stare at text or use Gnumeric to get my plots.
 And all the other applications (like virt-manager or
 gnome-system-monitor) that do plotting look rather crappy and their
 plots don't provide a lot of features (no zooms, no tooltips with
 actual values, no ability to expand or collapse certain parts).
 However, is a plotting widget a useful addition to GTK? If it works
 well, it would surely enable people to show lots of useful statistics
 that we'd all be thankful for - collecting them is not hard after all,
 but making their output useful is. I'm sure a lot of people would like
 bandwidth graphs in NetworkManager, page load performance graphs in
 Epiphany or an interactive bootchart. Even if it's just the
 developers using it to improve the rest of the world.
 That said, such a widget would need a simple interface - both in API
 and UI, and I'm not seeing anybody working on that. But I'd be very
 interested.

The part I found frustrating while working on scrolling[1] graphs was
coming up with a good model for storing data points. Especially when you
consider being able to graph different scales or modes of graphs. Say
heatmap, 2d plot, 3d plot, etc. Linear or logarithmic scales, etc. And
then also abstracting the look of the plot and the renderers.

Below is a list of things that come to mind. I'm kind of forcing it, not
particularly attached to the list below. I'm just trying to provide some
diversity.

VALIDATION
Many developers in the web world have become accustom to validating
the contents of forms before submitting them. While we would often argue
against allowing invalid input in the first place, that can often
confuse users. In this case, allowing the input and providing an
accurate reason why the input is invalid yields better results. I'm not
sure what a good API here would look like, but it needs to be flexible
enough to work with built-in and custom widgets.

DOCKABLE PANELS
There is an in-between that might be reachable instead of a full docking
library. The idea is more of panels. It's like float-able tool palette
that can be joined together. GIMP has this, and it's pretty bad. Which
could be an argument against it. But you can see a good implementation
in OmniGraffle[2] for OS X.

MENU BUTTON
A GtkButton that shows a menu when clicked (and handles positioning,
etc). Some would just use a combobox, but I find them pretty different.
You'll find this sort of menu button in various VMware products on
Linux. (I know the fullscreen toolbar used to have it at least).

WIDGET STACK
Like a notebook with no tabs or decoration. You push and pop widgets
on and off the stack. This is the navigational structure often found on
iOS. The reason I think abstracting it might make sense is more about
animating between widgets once Gtk starts landing animation (post
clutter integration obviously). It would be great if this nicely
integrated with a navigation bar type widget. Here[3] is a video of
some crappy animation code I wrote to do this.

ENTRY COMPLETION
We already have entry completion, but it would be much more useful if it
let you see the list of possible completions.

Cheers,

[1] http://audidude.com/?p=470
[2]
http://westergaard.eu/wp-content/uploads/2010/11/OmniGraffle-Professional-001.png
[3] http://www.youtube.com/watch?v=lp6ceGP-6vU


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

Re: Announce: glib-jsonrpc

[Christian Hergert]

On Wed, 2012-01-04 at 11:40 +0100, Joakim Sindholt wrote:
 No flames, just reminding you that there is a specification and we
 should adhere to it 100%, or in some cases maybe even be liberal (see
 my
 json_rpc_bridge_{request,notify}_verbatim, which I put in both for
 performance and non-conforming 3rd party reasons)

My mistake, I didn't realize there was a spec for this. In that case, it
is not what I'm looking for.

-- Christian


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

Re: Announce: glib-jsonrpc

[Christian Hergert]

Hi,

On Tue, 2011-12-27 at 06:52 +0200, Dov Grobgeld wrote:
 I created jsonrpc client/server (http://json-rpc.org/) library through
 glib/gio for remote controlling my application. It is available at:
 
 https://github.com/dov/glib-jsonrpc
 
 Comments and contributions are welcome.

Just got back from holiday and thought I'd post a few comments.

First off, I think this sort of thing is useful. Especially when you
consider the possibilities of automatically discovering applications
running near you using avahi. (A remote control application becomes
trivial).

I'm not a fan of the approach to hand-writing the HTTP responses. There
are so many quirks in HTTP clients. SoupSessionAsync suits the job well
and scales more than well enough for this use-case. I imagine it would
also make it easier to handle multiple async commands concurrently.

As for the API, I'm not a huge fan of registering commands with a
generic callback scheme. It requires lots of boilerplate code which we
used to deal with in the early DBUS days (well, if you support
parameters, not sure this does yet). I would like to see a design where
you register a GObject at a path, like GDBUS, and GObject Introspection
is used to route the given method. Parameters would be passed in as the
POST body with a Content-Type of application/json. Then, a single,
generic marshaller could be written to convert the argument parameters.

Additionally, this would allow for discovery of a given methods
parameters with a GET request to the given method by describing them in
a JSON response. Or a list of methods available with a GET to the
objects path.

And at this point, I expect flames about re-implementing DBUS. However,
I still find it useful in cases where DBUS clients aren't viable (JSON
API server, application controllable by iOS/Android, etc).

Cheers,

-- Christian


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

Re: I have a problem

[Christian Hergert]

On May 28, 2011, at 2:01 PM, Benjamin Otte wrote:

 * There's button(s) that say  ( Notes | Edit )
 How are these buttons different from notebooks? Is it just visually
 different or is it a completely different interaction? Because from
 the interaction described it looks like a notebook to me, just with a
 different UI. But I can't really pinpoint what's missing from
 GtkNotebook for this. Also, should we try to get rid of notebooks and
 replace it with buttons like these in other places?

I don't have a lot to say here, so I'll try to keep it brief. I think we need 
to approach many of these problems on a case by case basis. For example, in the 
notebook case, I think we can extract what the real problem is. The designer 
wants a way to switch between content within a particular area of the design. 
The fact that we attach notebook tabs to a side of this is simply one design 
metaphor for the act of switching. Perhaps, in this _one_ particular case, we 
need to extract the navigation of a stack of widgets from the stack of widgets 
itself, to fulfill the needs of the designers. Because, certainly, tabs can't 
be the solution to everything. (Breadcrumbs, nautilus navigation buttons, etc, 
all seem to fit within this metaphor).

I understand that you can just use a radio button group to switch the pages 
manually while not showing the notebook tabs. I've certainly done that before, 
and maybe that is enough. I don't know.

Cheers,

-- Christian

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

Re: GtkBuilder syntax for property bindings

[Christian Hergert]

On Fri, 2011-05-06 at 13:04 +0200, Denis Washington wrote:
 The main issue with this approach is what to do with two-way bindings. 
 One approach would be to make this a property of bind, but then, 
 bind wouldn't appear in every property it influences anymore. 
 Alternatively, the parser could be required to recognize direct cyclic 
 binding declarations (A binds to B, B binds to A) and collapse them into 
 a single two-way binding, which retains the 
 bind-only-affects-the-property-it-appears-in property; the parser 
 would be complicated by this, though.

Since GBinding, is itself, an object, why not just have the GBinding
instance represented in the GtkBuilder XML. The normal object syntax
might work as well:

  object classGBinding id=some_binding
property name=sourceobject1/property
property name=targetobject2/property
  /object

I think this would mean the majority of work is how to make it easy to
manage from within Glade.

Just a thought,

-- Christian


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

Re: GtkApplication and argc/arv

[Christian Hergert]

On Thu, 2011-02-24 at 13:11 +0800, Wen-Yen Chuang wrote:
 
 b.) Running multiple versions of the same application
 For example, running firefox 3.5, 3.6, and 4.0 at the same
 time. 

I don't think your example actually works without running each instance
using a different firefox user profile. I don't see using a different
application-id in gtk_applicaion_new() fundamentally different than
having multiple user profiles for each concurrent version of firefox.

-- Christian

___
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

[Christian Hergert]

On Mar 2, 2010, at 2:55 PM, Filippo Argiolas wrote:

To be fair I don't think you completely got what I was trying to say.
I cited the breadcrumb because it's usually visually styled as a group
of buttons (that behave like radios plus some more complicated logic)
grouped together into a single big button that contains several
ones. If you look at the screenshots in that link I think it's pretty
clear, I'd like a way to visually merge together several buttons
into a grouping container. Look at this mockup too, it should make it
clear enough:
http://people.gnome.org/~fargiolas/toggle-button-mockup.png


I don't want to detract from your conversation, but in case you  
haven't written up code for that toggle button mockup, I wrote one  
last year (in python, c, and c#).


http://audidude.com/?p=61
http://github.com/chergert/custom-gtk-widgets/tree/master/gtkmodebutton

Cheers,

-- Christian

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

GDateTime

[Christian Hergert]

Hello good folks,

I spent some of my free time recently putting together a DateTime
solution for GLib.  It is starting to get to the point where it is
usable.  Most of the work now seems to be finishing up string parsing,
polish, improving documentation, and i18n/l10n compliance for which I
could use suggestions and comments from the community.

The GDateTime opaque type represents a date and time down to
100-nanosecond intervals between 1/1/1 and 12/31/.  I find it
considerably easier to use when compared to time_t, struct tm, and other
limiting time types.

My branch is the datetime branch available at
git://git.dronelabs.com/glib.

This is my first attempt at building something for glib so please let me
know if I've not followed some conventions properly.

-- Christian


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

Re: libdispatch vs glib

[Christian Hergert]

I think Iris sits pretty well as a standalone library.  The only real 
overlap it has with GLib is scheduling work-items to a thread.  The 
schedulers in Iris, however, rely on a lot of the other data-structures 
which is probably a bit too much to add.


I guess IrisQueue overlaps with GAsyncQueue as well.  I needed to 
abstract it so I could have various queue implementations such as 
work-stealing and lock-free queues.


I'm working on some documentation as well.

-- Christian


cee1 wrote:

Hi Christian,
Have you considered to merge some of the core functions of your library
to glib?

BTW, it would be very good if you can provide some documents.

2009/9/16 Christian Hergert ch...@dronelabs.com
mailto:ch...@dronelabs.com

I forgot to mention that I have an example of how to use it which is
a serialization library for GLib/GObject called Catalina.  It does
transparent serialization and optionally compression of the main
glib types and GObjects.

It takes TDB and builds concurrent transactions using message passing.

http://git.dronelabs.com/catalina

-- Christian


Christian Hergert wrote:

Hi,

Have you see my library iris[1]?

It includes a lot of the same sort of stuff (albeit not nearly the
attention and optimization yet) and includes:

* a work-stealing scheduler thats 8x faster than GThreadPool
on my local machines (dual and quad-cores)
* message-passing using ports/receivers
* a dynamic scheduler manager that can scale threads as neaded
and tear them back down. applications can have multiple schedulers
based on what they want if needed.
* reusable lock-free data structures such as Queue, FreeList, Stack,
and Round-Robin.
* IrisTask which is like Twisted's Deferred for
addCallback/addErrback
type functionality.
* iris_arbiter_coordinate() which is a reader/writer lock
implemented
asynchronously using message passing (on top of ports/receivers)
* bindings for python, vala, and gobject-introspection (vala
might be
out of date though).
* GMainLoop integration for scheduling callbacks in the mainloop.

One major thing it lacks

* eyes looking at the code
* documentation

But best of all, its written fully using GLib :-)

I wrote this during my spring/summer after I quit my job. However I
start a new one in a few weeks but would love some input from
others and
ideally more people to commit features and generally use it.

Cheers,

-- Christian

[1] http://git.dronelabs.com/iris

cee1 wrote:

Hi all,
Following is a comparison between libdispatch and glib, just for
interest.

First, libdispatch is the user space part of apple's
GDC(Grand Central
Dispatch), resides at http://libdispatch.macosforge.org.
There is also
an introduction at
http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html.

At first glimpse, libdispatch provides three different types
of dispatch
queues:

1. Main queue: equivalent of glib's main event loop
2. Global queue: backed up by a thread pool. All the jobs
sent to
this queue, will be executed in arbitrary threads
asynchronously.
3. Private queue: jobs in this queue will be executed serially.

Both private queue and main queue are just threads in global
queue. It
should be more user-friendly than combining GMainLoop and
GThreadPool,
e.g. process GSource in another thread (i.e using thread
pool in the
callback of that GSource).

The private queue can be considered as a pipeline (imaging
GstPipeline
in gstreamer).

libdispatch also has a type of dispatch_source_t, equivalent
of GSource,
but the callback is running in global queue, (hence, a
different thread)

libdispatch is built on an extension to C (blocks), which is
like
GClosure.





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

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



___
gtk-devel-list mailing list
gtk-devel-list

Re: libdispatch vs glib

[Christian Hergert]

Hi,

Have you see my library iris[1]?

It includes a lot of the same sort of stuff (albeit not nearly the 
attention and optimization yet) and includes:


 * a work-stealing scheduler thats 8x faster than GThreadPool
   on my local machines (dual and quad-cores)
 * message-passing using ports/receivers
 * a dynamic scheduler manager that can scale threads as neaded
   and tear them back down.  applications can have multiple schedulers
   based on what they want if needed.
 * reusable lock-free data structures such as Queue, FreeList, Stack,
   and Round-Robin.
 * IrisTask which is like Twisted's Deferred for addCallback/addErrback
   type functionality.
 * iris_arbiter_coordinate() which is a reader/writer lock implemented
   asynchronously using message passing (on top of ports/receivers)
 * bindings for python, vala, and gobject-introspection (vala might be
   out of date though).
 * GMainLoop integration for scheduling callbacks in the mainloop.

One major thing it lacks

 * eyes looking at the code
 * documentation

But best of all, its written fully using GLib :-)

I wrote this during my spring/summer after I quit my job.  However I 
start a new one in a few weeks but would love some input from others and 
ideally more people to commit features and generally use it.


Cheers,

-- Christian

[1] http://git.dronelabs.com/iris

cee1 wrote:

Hi all,
Following is a comparison between libdispatch and glib, just for interest.

First, libdispatch is the user space part of apple's GDC(Grand Central
Dispatch), resides at http://libdispatch.macosforge.org. There is also
an introduction at
http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html.

At first glimpse, libdispatch provides three different types of dispatch
queues:

   1. Main queue: equivalent of glib's main event loop
   2. Global queue: backed up by a thread pool. All the jobs sent to
  this queue, will be executed in arbitrary threads asynchronously.
   3. Private queue: jobs in this queue will be executed serially.

Both private queue and main queue are just threads in global queue. It
should be more user-friendly than combining GMainLoop and GThreadPool,
e.g. process GSource in another thread (i.e using thread pool in the
callback of that GSource).

The private queue can be considered as a pipeline (imaging GstPipeline
in gstreamer).

libdispatch also has a type of dispatch_source_t, equivalent of GSource,
but the callback is running in global queue, (hence, a different thread)

libdispatch is built on an extension to C (blocks), which is like GClosure.




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

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

Re: libdispatch vs glib

[Christian Hergert]

I forgot to mention that I have an example of how to use it which is a 
serialization library for GLib/GObject called Catalina.  It does 
transparent serialization and optionally compression of the main glib 
types and GObjects.


It takes TDB and builds concurrent transactions using message passing.

  http://git.dronelabs.com/catalina

-- Christian

Christian Hergert wrote:

Hi,

Have you see my library iris[1]?

It includes a lot of the same sort of stuff (albeit not nearly the
attention and optimization yet) and includes:

* a work-stealing scheduler thats 8x faster than GThreadPool
on my local machines (dual and quad-cores)
* message-passing using ports/receivers
* a dynamic scheduler manager that can scale threads as neaded
and tear them back down. applications can have multiple schedulers
based on what they want if needed.
* reusable lock-free data structures such as Queue, FreeList, Stack,
and Round-Robin.
* IrisTask which is like Twisted's Deferred for addCallback/addErrback
type functionality.
* iris_arbiter_coordinate() which is a reader/writer lock implemented
asynchronously using message passing (on top of ports/receivers)
* bindings for python, vala, and gobject-introspection (vala might be
out of date though).
* GMainLoop integration for scheduling callbacks in the mainloop.

One major thing it lacks

* eyes looking at the code
* documentation

But best of all, its written fully using GLib :-)

I wrote this during my spring/summer after I quit my job. However I
start a new one in a few weeks but would love some input from others and
ideally more people to commit features and generally use it.

Cheers,

-- Christian

[1] http://git.dronelabs.com/iris

cee1 wrote:

Hi all,
Following is a comparison between libdispatch and glib, just for
interest.

First, libdispatch is the user space part of apple's GDC(Grand Central
Dispatch), resides at http://libdispatch.macosforge.org. There is also
an introduction at
http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html.

At first glimpse, libdispatch provides three different types of dispatch
queues:

1. Main queue: equivalent of glib's main event loop
2. Global queue: backed up by a thread pool. All the jobs sent to
this queue, will be executed in arbitrary threads asynchronously.
3. Private queue: jobs in this queue will be executed serially.

Both private queue and main queue are just threads in global queue. It
should be more user-friendly than combining GMainLoop and GThreadPool,
e.g. process GSource in another thread (i.e using thread pool in the
callback of that GSource).

The private queue can be considered as a pipeline (imaging GstPipeline
in gstreamer).

libdispatch also has a type of dispatch_source_t, equivalent of GSource,
but the callback is running in global queue, (hence, a different thread)

libdispatch is built on an extension to C (blocks), which is like
GClosure.




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

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

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

Re: another quartz maintainance request (patch review commit)

[Christian Hergert]

For those interested, I've been maintaining a branch with various 
patches sitting in bugzilla and a few of my own.  This is the branch 
that was chosen for the most recent release of Mono on OSX so that 
MonoDevelop can provide a better experience for our Mac users.


http://git.dronelabs.com/gtk+/?h=macos-fixes
git://git.dronelabs.com/gtk+

-- Christian

Paul Davis wrote:

This bug report: https://bugzilla.gnome.org/show_bug.cgi?id=594738
contains a potentially important fix to make 2+ monitors work with
GTK/Quartz. Those of us in the GTK/Quartz community would appreciate
someone with commit rights (1) looking at christian's approach and
forming a judgement on whether its the right approach to the problem
(2) committing this or some eventual fix.

Things are looking pretty bad for GTK/Quartz maintainance right now.
Nobody that has commit access appears to be in a position to test
(i.e. care) about Quartz fixes; those who care do not have commit
access. It would be hugely preferable (IMHO) for us to not to have to
branch to an alternate git repo ...

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

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

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Christian Hergert]

Have you profiled to see if the bottleneck is CPU bound?  If its IO 
bound, you will only cause more contention by adding threading.


At minimum, using a thread (or async gio) to load files and another 
thread that just thumbnails might be a good idea.


Cheers,

-- Christian

Mark wrote:

  is there anyone here that has experienced with this? is there
anyone i an work with on this? actually anyone that could help me
through this? i'm brand new in glib and new to programming in general.
I would like to give this a try but i'm afraid i can't do this alone.
So any information about this, help and thoughts would be nice.

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

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Christian Hergert]

Hi,

What you mentioned is good information to start hunting.  Was the CPU 
time related to IO wait at all?  Always get accurate numbers before 
performance tuning.  Measure, measure, measure or so the mantra goes.


Unfortunately, the symptom you see regarding IO will very likely change 
under a different processing model.  If the problem is truly CPU bound 
then you will only be starting IO requests after you were done 
processing.  This means valuable time is wasted while waiting for the 
pages to be loaded into the buffers.  The code will just be blocking 
while this is going on.


What could be done easily is every time an item starts processing it 
could asynchronously begin loading the next image using gio.  This means 
the kernel can start paging that file into the vfs cache while you are 
processing the image.  This of course would still mean you are limited 
to a single processor doing the scaling.  But if the problem is in fact 
cpu bound, that next image will almost always be loaded by time you 
finish the scale meaning you've maximized the processing potential per core.


To support multi-core, like it sounds like you want, a queue could be 
used to store the upcoming work items.  A worker per core, for example, 
can get their next file from that queue.  FWIW, I wrote a library, 
iris[1], built specifically for doing work like this while efficiently 
using threads with minimum lock-contention.  It would allow for scaling 
up threads to the number of cores and back down when they are no longer 
needed.


Cheers,

[1] http://git.dronelabs.com/iris

-- Christian

Mark wrote:

On Fri, Aug 28, 2009 at 10:45 PM, Christian Hergertch...@dronelabs.com  wrote:

Have you profiled to see if the bottleneck is CPU bound?  If its IO bound,
you will only cause more contention by adding threading.

At minimum, using a thread (or async gio) to load files and another thread
that just thumbnails might be a good idea.

Cheers,

-- Christian

Mark wrote:

  is there anyone here that has experienced with this? is there
anyone i an work with on this? actually anyone that could help me
through this? i'm brand new in glib and new to programming in general.
I would like to give this a try but i'm afraid i can't do this alone.
So any information about this, help and thoughts would be nice.


Hi,

I haven't done io profiling but i did calculate the disc usage for
those 1927 files. and every benchmark was WAY below what my hdd could
handle (Spinpoint F1 1TB hdd and it can handle roughly 100MB/sec).

As for the CPU. i did profiling there. i just opened up gnome's
system monitor tool and just watch it during the benchmark. That gave
the result of 1 core running at 100% and 3 other cores idle thus there
is a cpu bottleneck with thumbnail generating.

About your suggestion for loading in a thread and thumbnailing in
another thread.. don't you get in big problems if the pc is
thumbnailing faster then it's loading? Or is that a impossible
scenario?

Mark.

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

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Christian Hergert]

On Fri, Aug 28, 2009 at 11:49 PM, Christian Hergertch...@dronelabs.com  wrote:

Hi,

What you mentioned is good information to start hunting.  Was the CPU time
related to IO wait at all?  Always get accurate numbers before performance
tuning.  Measure, measure, measure or so the mantra goes.


Perhaps a stupid question but what is a good way of profiling io? cpu
is easy but i've never done io.
In this case my hdd is certainly able to do more then 10 thumbnails
per second however i could see a potential issue when someone with a
slower hdd and a faster cpu then mine is thumbnailing a lot of images.
There the hdd will likely be the bottleneck.


You can do something really crude by reading from /proc/pid/* (man proc 
for more info).  Or you could try using some tools like sysstat, 
oprofile, system-tap, etc.  We really need a generic profiling tool that 
can do all of this stuff from a single interface.  However, at the 
current time, I've been most successful with just writing one off 
graphing for the specific problem.  For example, put in some g_print() 
lines and grep for those and then graph them using your favorite plotter 
or cairo goodness.



Unfortunately, the symptom you see regarding IO will very likely change
under a different processing model.  If the problem is truly CPU bound then
you will only be starting IO requests after you were done processing.  This
means valuable time is wasted while waiting for the pages to be loaded into
the buffers.  The code will just be blocking while this is going on.


And how can i test that?


ltrace works for simple non-threaded applications.  Basically you should 
see in the profiling timings that one work item happens sequentially 
after the previous such as (load, process, load, process, ...)


I would hate to provide conjecture about the proper design until we have 
more measurements.  It is a good idea to optimize the single threaded 
approach before the multi-core approach since it would have to be done 
anyway and is likely less complex of a problem before the additional 
threads.



What could be done easily is every time an item starts processing it could
asynchronously begin loading the next image using gio.  This means the
kernel can start paging that file into the vfs cache while you are
processing the image.  This of course would still mean you are limited to a
single processor doing the scaling.  But if the problem is in fact cpu
bound, that next image will almost always be loaded by time you finish the
scale meaning you've maximized the processing potential per core.


That sounds like a nice way to optimize it for one core. But could
there be any optimization possible in my case? since i have 100% cpu
usage for one core with just the benchmark.


You can't properly optimize for the multi-core scenario until the 
single-core scenario is fixed.



To support multi-core, like it sounds like you want, a queue could be used
to store the upcoming work items.  A worker per core, for example, can get
their next file from that queue.  FWIW, I wrote a library, iris[1], built
specifically for doing work like this while efficiently using threads with
minimum lock-contention.  It would allow for scaling up threads to the
number of cores and back down when they are no longer needed.


That sounds very interesting.
Just one question about the queue. Would it be better to thread the
application (nautilus) or the library (glib)? If your answer is the
library then the queue has to be passed from nautilus to glib. I would
say glib because all application have benefit from it without
adjusting there code.


I haven't looked at this code in detail yet, so I cannot confirm or 
deny.  My initial assumption would be that the thumb-nailing API (again, 
I have no experience with it yet) should be restructured around an 
asynchronous design (begin/end methods) and the synchronous 
implementation built around that.  And of course, nobody should use the 
synchronous version unless they *really* have a reason to.


FWIW, I would be willing to help hack on this, but I'm swamped for at 
least the next few weeks.


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

Re: Notes and thoughts on the GTK+ meeting at GUADEC

[Christian Hergert]

Alberto Ruiz wrote:

2009/8/19 Cody Russellbrats...@gnome.org:

On Tue, 2009-08-18 at 15:27 -0700, Christian Hergert wrote:

One of the items I haven't seen discussed is input validation.  Web
frameworks such as Rails and Django spent a great deal of time
making
these easy to work with and I think that it should be considered for
gtk+ 3.0.


Isn't this something to be considered after the 3.0 release? I can't
think of any reason not to do it during the after 3.0 lifecycle.


I think that's fair.  However, with proper direction and input I think I 
could still start on it now.  Of course, I don't want to take what 
precious time people have for working towards 3.0.


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

Re: Notes and thoughts on the GTK+ meeting at GUADEC

[Christian Hergert]

Hello,

One of the items I haven't seen discussed is input validation.  Web  
frameworks such as Rails and Django spent a great deal of time making  
these easy to work with and I think that it should be considered for  
gtk+ 3.0.


FWIW, I hacked up a crude idea[1] a few months ago.  If others are  
interested in this feature, and willing to give me API guidance, I'd  
be willing to spend the time to implement it.


As primary features, I think it should cover,

  * Integration with GtkBuilder to build validations at design time
  * Ability to chain a validation request on button activate in a  
dialog and suppress the event if validation fails
  * Validation split into reusable validators and reusable style  
modifiers

- Range validator, Regex validator, etc
- Style modifier, or with css we can add/remove classes based on  
validation result


Comments and suggestions appreciated,

-- Christian

[1] http://git.dronelabs.com/gtk-validation/

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