Re: Gtk+4.x and broadway ( and other remote options )
Sorry, there is no real change, I still have no time to work on broadway "for real". I just spent a couple of days converting the broadway backend to match the changes that are happening in gtk4 "for fun". Unfortunatelly it just ended up with me and a huge todo-list and no more time to work on it... Maybe someone else is interested in consulting work on it though? On Thu, Dec 7, 2017 at 6:13 AM, Daniel Kasak <d.j.kasak...@gmail.com> wrote: > Hi Alexander. I appreciate you clarifying this for us. It was a nice > surprise to read on Phoronix recently that you're still committing fixes & > improvements to the broadway codebase. I'd like to understand - has > anything changed in the past year that's brought you back to broadway? I > know there are still a handful of users around who would love to see this > continue ( some of them email me directly, and I have to answer: "sorry - > I'm just a user as well" ). If throwing money at the problem works, we > might be able to arrange that, maybe via a crowdfunding page, or something > less formal. Would it be worth it to you or Redhat? > > Dan > > On Fri, Dec 16, 2016 at 2:25 AM, Alexander Larsson <al...@redhat.com> > wrote: > >> On ons, 2016-12-07 at 14:18 +1100, Daniel Kasak wrote: >> > Hi all. >> > >> > I posting here in response to comments on bug: >> > https://bugzilla.gnome.org/show_bug.cgi?id=775680 ( summary: broadway >> > support likely to be removed from Gtk+4.0 ). >> > >> > I think it would be a massive pity to drop broadway support from gtk. >> > It's been a god-send for me and those I work with - it provides the >> > best remote access to gtk apps and performs way better than vnc. I've >> > actually been working on an authentication + transparent proxy for >> > broadway, so multiple users can access multiple apps all via https on >> > port 443: https://tesla.duckdns.org/transparent-proxy-for-broadway-gt >> > k3-html5-backend/ >> >> So, there are two issues with broadway. >> >> First of all, I wrote it mostly as a proof of concept of an interesting >> idea. I have zero cycles to spend on it anymore, nor do any of the >> other people who currently work on Gtk+. Its still there, because it >> just works and is not really a burden on the existing code unless you >> use it. >> >> Secondly, while it just keeps working in gtk3, the same is not true for >> Gtk4. We're doing massive changes to the internals of the drawing >> model, with the end goal of having a much more modern base targeting >> how current GPU hardware works. This is very much not how broadway >> works though, so there is some conflict here. For now, we have fallback >> code for the rendering that keeps broadway working, so we're keeping it >> around, but if at any point broadway becomes a problem to keep working >> we're going to drop. I don't really forsee this happening at the >> moment, but there are no guarantees. >> >> -- >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> =-=-=-=-=-=-=-= >> Alexander Larsson Red Hat, Inc >>al...@redhat.comalexander.lars...@gmail.com >> He's a lonely bohemian shaman on his last day in the job. She's a >> beautiful psychic schoolgirl looking for love in all the wrong places. >> They fight crime! >> > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.com alexander.lars...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of wip/carlosg/event-delivery
On Wed, 2017-05-17 at 17:45 +0200, Carlos Garnacho wrote: > Hej hej, > > On Wed, May 17, 2017 at 3:27 PM, Alexander Larsson <al...@redhat.com> > wrote: > > On Wed, 2017-05-17 at 01:04 +0200, Carlos Garnacho wrote: > > > Hey, > > > > > > On Tue, May 16, 2017 at 8:24 PM, Matthias Clasen > > > <matthias.cla...@gmail.com> wrote: > > > > On Tue, May 16, 2017 at 1:25 PM, Carlos Garnacho <carlosg@gnome > > > > .org > > > > > wrote: > > > > > > > > > > > > > > > > - interactive overlay: buttons over entry get prelights > > > > > > and > > > > > > clicks > > > > > > instead of the entry stealing them > > > > > > > > > > Hmm, the demo however sets the overlay as passthrough? > > > > > https://git.gnome.org/browse/gtk+/tree/demos/gtk-demo/overlay > > > > > .c#n > > > > > 60 > > > > > > > > > > > > There's two overlay. One is passthrough, the other isn't: the > > > > "Numbers" are > > > > supposed to be passthrough, while the entry is supposed to get > > > > input. > > > > > > Not what I see in code :). AFAICS both the entry and the label > > > are > > > children of a vbox, which is the only, pass-through overlay. The > > > inspector seems to confirm this hierarchy. > > > > > > And this means gtk3 is broken :/, as it's essentially the same > > > thing > > > there. > > > > The test was added especially to test the case of a generally > > transparent/shaped overlay that had some non-transparent child > > widget. > > > > It works, because the entry has a GdkWindow that is not pass > > through. > > From the gdk_window_set_pass_through docs: > > > > Note that a window with @pass_through %TRUE can still have a > > subwindow > > without pass through, so you can get events on a subset of a > > window. > > And in that cases you would get the in-between related events such > > as > > the pointer enter/leave events on its way to the destination > > window. > > > > In general, pass-through is related to a particular window, not the > > entire sub-hierarchy. This matches the css pointer-events: none > > behaviour, and anything else would be far less useful. > > Hmm, I see, missed those bits. Which doesn't match too well to a > non-GdkWindow/GdkEventMask based world... how do we express this > selective pass-through across complex portions of a widget hierarchy? > The best I can think of is making GtkOverlay implement ::pick, make > it > peek the deepmost widget of the picking operation, and check whether > any widgets on the way up to the overlay child have event controllers > attached, that seems the closest to non-passthrough child windows. I think we have to make GdkWindow::passthrough a feature of GtkWidget instead, and respect it in the default pick operation. Its a bit more work for people to set passthrough on all the widgets, but its at least possible. Conceptually one could have passthrough be a tri-state, with FALSE, TRUE and SAME-AS-PARENT. I guess this is what CSS does essentially, where you set pointer-events to "inherit". -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an all-American native American Green Beret haunted by memories of 'Nam. She's an artistic mute snake charmer from a family of eight older brothers. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of wip/carlosg/event-delivery
On Wed, 2017-05-17 at 01:04 +0200, Carlos Garnacho wrote: > Hey, > > On Tue, May 16, 2017 at 8:24 PM, Matthias Clasen > <matthias.cla...@gmail.com> wrote: > > On Tue, May 16, 2017 at 1:25 PM, Carlos Garnacho <carl...@gnome.org > > > wrote: > > > > > > > > > > - interactive overlay: buttons over entry get prelights and > > > > clicks > > > > instead of the entry stealing them > > > > > > Hmm, the demo however sets the overlay as passthrough? > > > https://git.gnome.org/browse/gtk+/tree/demos/gtk-demo/overlay.c#n > > > 60 > > > > > > There's two overlay. One is passthrough, the other isn't: the > > "Numbers" are > > supposed to be passthrough, while the entry is supposed to get > > input. > > Not what I see in code :). AFAICS both the entry and the label are > children of a vbox, which is the only, pass-through overlay. The > inspector seems to confirm this hierarchy. > > And this means gtk3 is broken :/, as it's essentially the same thing > there. The test was added especially to test the case of a generally transparent/shaped overlay that had some non-transparent child widget. It works, because the entry has a GdkWindow that is not pass through. From the gdk_window_set_pass_through docs: Note that a window with @pass_through %TRUE can still have a subwindow without pass through, so you can get events on a subset of a window. And in that cases you would get the in-between related events such as the pointer enter/leave events on its way to the destination window. In general, pass-through is related to a particular window, not the entire sub-hierarchy. This matches the css pointer-events: none behaviour, and anything else would be far less useful. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a shy Republican ex-con with a passion for fast cars. She's a wealthy wisecracking nun fleeing from a Satanic cult. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Review of wip/carlosg/event-delivery
I took a quick look at the wip/carlosg/event-delivery branch.
Here are some things in the tests that seems broken from interactive
testing:
testgtk
- click on close button gives:
Gtk-CRITICAL **: _gtk_widget_captured_event: assertion
'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
This also happens in many other cases
- button box:
Click on button, hold down, mouse to other button => it
prelights. Should not have gotten enter notify due to implicit
grab.
- eventbox:
above child is not working
- expander:
Press on expander, mouse outside window, release, now the
expander expands when you enter the window
- panes:
Resizing the pane doesn't work
- spinbutton:
clicking on the buttons in the spinbutton shows really weird
prelight behaviour
- spinbutton:
Can't hold down button on spinbutton button to step
- test scroll:
Can't keep scrolling when cursor is outside toplevel (implicit
grab not working)
gtk4-demo:
- After startup, if I click on last row ("Menus") it doesn't properly
repaint the selected row
- combo boxes: mouse press + move on combo does not work, must click
and then move
- icon view basics: Scrolling the icon view verticaly doesn't
repaint correctly
- list box: click on expand button, then you can use enter to
activate it, then mouse to expand button on row below => hover,
now hit enter. the button scrolls away from the mouse, but
it doesn't unhover
- interactive overlay: buttons over entry get prelights and clicks
instead of the entry stealing them
- popovers: The icons in the entry doesn't accept clicks, nor do the
calendar
- tree view/list store - size allocation is broken, and "Fixed?"
checkbutton is not working
Some code review:
I worry about the GtkWidget::pick vfunc and the consistency of the
widget geometry. The implementation of gtk_widget_real_pick relies on
the widget hieararhy being correctly allocated, which is only true
directly after a layout pass. For instance, the current code will
re-pick immediately whenever the focus target is destroyed, which will
typically happen in the middle of some random code that changes
the widget hierarchy. You can't rely on the widget allocation at
this point. It may be uninitialized for new widgets, or just wrong
if some other widget got removed which will cause the widget to shift.
In the current framework our events are based on GdkWindow positions,
and these are set at size allocation time and are valid until the next
size allocation, so it doesn't have this problem.
I think picking fundamentally has to be tied to the layout cycle, we
can't just do it whenever we feel like it. For more thoughts about
this, see my previous review on this:
https://mail.gnome.org/archives/gtk-devel-list/2017-April/msg0.html
The default picking system always treats widgets as rectangular. This
is a regression at least for GtkPopover, which currently uses input
shapes to get correct event handling for the rounded corners. However,
it strikes me that if we make it a slightly bit smarter we could
handle CSS corners in general vs input. For instance, we could have
"mouse enter" on a button with rounded corners only when the pointer
is actually inside the css box (i.e. not when its on the rounded part
of the corner).
GtkPointerFocus is not refcounted, and is seemingly freed in various
callbacks. I can't swear this is an issue, but it seems likely that we
can run into cases where some code acesses it and then it gets freed
due to some state change in a function call and when we get back
we continue to access the freed object.
The notify_types for the crossing events seem wrong:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkmain.c?h=wip/carlosg/event-delivery=c43ce71c21da075b53f1c00bd286e2ccfd1312aa#n1376
This sends the same notify type to all the widgets involved in the
crossign events, which is not right. The first and last widget
to get events should get different details. See this for the details:
https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabbed.html
This seems to cause issues like the one worked around by:
https://git.gnome.org/browse/gtk+/commit/?h=wip/carlosg/event-delivery=0b569fd6827e1728c8dbf67440535dc87694983b
I wonder if at some point we could move the map vfunc to the toplevel?
Should any child widget ever need to do anything on map?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a one-legged day-dreaming farmboy who hides his scarred face behind
a mask. She's a vivacious cigar-chomping politician with the power to see
death. They fight crime!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
events-delivery branch review - crossing events
So, I took a quick look at the event-delivery branch. One fundamental thing that it is currently missing is the handling of crossing events due to size allocation changes. In the simple case this is just a label changing context, making the widget wider which changes the widget under the pointer. However, there is also some real complexity in this. For instance, it's possible to get loops this way, such as if the :hover state causes the new widget position to be outside the pointer. If you look at how CSS handles this, the specification says: User agents are not required to reflow a currently displayed document due to pseudo-class transitions. For instance, a style sheet may specify that the 'font-size' of an :active link should be larger than that of an inactive link, but since this may cause letters to change position when the reader selects the link, a UA may ignore the corresponding style rule. However, testing firefox and chrome[1] it seems in practice what happens is that :hover causes a reflow, but the new reflow does not in turn cause re-calculating the :hover state (until the next mouse event at least). This seems like like a pretty nice behaviour in a weird situation. In the current pre-event-delivery branch what happens in the layout cycle is this: 1) emit all events in the queue then freeze the event queue 2) emit update which triggers all animations etc 3) Do size machinery, possibly loop up to 4 times 4) Paint 5) Unfreeze events, possibly queueing a new frame In the above, a mouse enter event in 1 would cause a css property change, which would cause the cause the relayout in 3 to produce a new GdkWindow geometry, which in turn will emit new enter/leave events when the queue is unfrozen at 5 and which cause a new cycle the next frame. The frame clock will limit the cpu use from 100%, but its still not ideal to constantly switch between two states. Also, even if we don't get a loop the correct rendering is always delayed one frame. The question is how to handle this in the new model. The naive version would cause the hover css property to change immediately from size allocate, which will cause a layout loop that runs 4 times, and then paint. Another alternative is to keep a crossing event for this so that we can store it on the event queue, and this way we can reproduce the current behaviour. However, that strikes me as non-ideal too. An alternative would be to treat crossing events as level-triggered instead of edge-triggered, at most once a frame. Every frame, after the first iteration in the layout machinery we pick the current position for all pointers, and emit css state changes (as well as generic widget event callbacks). If any of these queue a resize we'll handle these in the next iteration, but we never generate further crossing events this frame, nor do we automatically schedule a new frame just due to this. This has some complications in semantics though. If you move the pointer between multiple widgets in one frame we will miss some crossing events that we would otherwise have seen. I don't think this is a problem in itself, because these would unlikely have resulted in something that would affect the final frame result (it would essentially be like the user moved the mousepointer so fast that it jumped over the inbetween widget completely). However, it is not entierly clear how to report the motion events that land in-between the two widgets that had the enter notify reported to them. Getting motion events without enter events is quite a change compared to the current semantics. Can we just drop these events? [1] https://jsfiddle.net/mp1u3ncy/ -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an immortal moralistic Green Beret looking for 'the Big One.' She's an elegant hypochondriac magician's assistant with her own daytime radio talk show. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSK review and ideas
On tor, 2016-12-15 at 13:15 -0500, Owen Taylor wrote: > On Thu, 2016-12-15 at 16:26 +0100, Alexander Larsson wrote: > > > > This combined with the fact that OpenGL makes it very hard, > > flickerly > > and generally poorly supported to do damage-style partial updates > > of > > the front buffer means we should consider always updating the > > entire > > toplevel each time we paint. This is what games do, and we need to > > make that fast anyway for e.g. the resize case, so we might as well > > always do it. That means we can further simplify clipping in > > general, > > because then we always start with a rectangle and only clip by > > rects, > > which i think means we can do the clipping on the GPU. > > Just because we need to be able to repaint the whole toplevel quickly > for resizing and other animations, and just because games repaint the > whole scene - that should not drive an assumption that there is no > value to clipped updating. Clipped updating is not done for speed - > it's done to reduce power consumption and to leave resources (GPU, > CPU, > memory bandwidth) for other usage. > > If a copy of Evolution in the background is using only 25% of system > resources to update a small progress bar at 60fps, that's not "60fps > - > success!", that's "2W of power - fail!" Well, things are not always so clear cut. Fundamentally, OpenGL doesn't have great primitives for clipping to a region of unbounded complexity. First of all, generally you have to supply entire buffers that have valid content everywhere. If you're lucky you can use extensions like buffer age so that you can track which part of the back buffer is up- to-date, but that requires double or tripple buffering, which itself brings up the memory use and possibly the the power use. Secondly, if you're painting to an old buffer where you want to update only the damage region, then you need to guarantee that all your drawing is completely clipped to the damage region. If this is a complex region, or just say two small rects far from each other, then scissoring is not good enough to do clipping for you. The alternative then is something like stencil buffers, but that means clipping on the pixel level, so you have to do a lot of work anyway, submitting geometry that you don't know will be clipped or not. Still, I guess we should try to do this as well as we can, especially if we want to keep any decent performance for the software fallback case. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an all-American small-town senator who hides his scarred face behind a mask. She's a radical bisexual fairy princess who don't take no shit from nobody. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSK review and ideas
On tor, 2016-12-15 at 11:22 -0500, Matthias Clasen wrote: > > Note that we do have a clip rect for widgets that can be larger than > the allocation. So we can have the best of both worlds: widgets can > opt in to drawing outside their alllocation by setting a clip, and we > can still cull everything whose clip rect doesn't intersect the (gsk) > clip. True, but we must have *a* clip which we know of a-priore, it can't be unbounded. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a jaded Republican barbarian whom everyone believes is mad. She's a sharp-shooting nymphomaniac angel who hides her beauty behind a pair of thick-framed spectacles. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GSK review and ideas
means we can further simplify clipping in general, because then we always start with a rectangle and only clip by rects, which i think means we can do the clipping on the GPU. Also related to clipping, we're currently not doing any culling at all. I think we need to make gtk_container_snapshot_child() take the current clip into consideration when recursing. Right now we're creating nodes for children that are not visible. Of course, such culling relies on the fact that the children don't draw outside their allocation. Culling seems quite important to be able to handle 1s of rows in a listbox. So maybe we need to actually clip every widget. The above kinda contradicts each other, so we need to decide what to do here. My hunch is that the natural approach is a bit of both, where we always repaint the entire window (ignoring the damage region), but clip each widget to the allocation. That means clipping becomes a simple int-rect intersection (not a full region_t) which can be done fast (and maybe on the GPU) while still allowing highlevel culling on the widget allocation level. Does that seem right? Related to this *again* is transformations. I don't think the way these work right now actually do the right thing. Consider for instance a clip node inside a transform node. For this to work right we need to transform the clip node rect to window coordinates, which may end up with a very weird region (esp. for a 3d transform!). Another example is if we have something inside the transformation that is more complex than a textured polygon, such as e.g. some GLSL code that renders a shadow or a rounded rect, then that code needs to respect arbitrary transformations during rendering, which is far from trivial! So I wonder if it isn't better to always consider a non-trivial transformation a place where you render the child node into an offscreen and then draw the result as a texture. (Althogh maybe we can special-case very simple cases like a transformed textured quad.) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a sword-wielding Amish master criminal on the run. She's a plucky antique-collecting Valkyrie with only herself to blame. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.x and broadway ( and other remote options )
On ons, 2016-12-07 at 14:18 +1100, Daniel Kasak wrote: > Hi all. > > I posting here in response to comments on bug: > https://bugzilla.gnome.org/show_bug.cgi?id=775680 ( summary: broadway > support likely to be removed from Gtk+4.0 ). > > I think it would be a massive pity to drop broadway support from gtk. > It's been a god-send for me and those I work with - it provides the > best remote access to gtk apps and performs way better than vnc. I've > actually been working on an authentication + transparent proxy for > broadway, so multiple users can access multiple apps all via https on > port 443: https://tesla.duckdns.org/transparent-proxy-for-broadway-gt > k3-html5-backend/ So, there are two issues with broadway. First of all, I wrote it mostly as a proof of concept of an interesting idea. I have zero cycles to spend on it anymore, nor do any of the other people who currently work on Gtk+. Its still there, because it just works and is not really a burden on the existing code unless you use it. Secondly, while it just keeps working in gtk3, the same is not true for Gtk4. We're doing massive changes to the internals of the drawing model, with the end goal of having a much more modern base targeting how current GPU hardware works. This is very much not how broadway works though, so there is some conflict here. For now, we have fallback code for the rendering that keeps broadway working, so we're keeping it around, but if at any point broadway becomes a problem to keep working we're going to drop. I don't really forsee this happening at the moment, but there are no guarantees. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a lonely bohemian shaman on his last day in the job. She's a beautiful psychic schoolgirl looking for love in all the wrong places. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Removal of embedded widgets in 4.x
On fre, 2016-11-11 at 11:41 +0800, fanc...@yahoo.com.tw wrote: > > > > > > > > > Hi, (Sorry if the e-mail does not look nice as I sent it from > > > > > > > > > my phone) In GTK+ git master embedded widgets were removed, along with the win32 and x variants. The thing is, gtkprintoperation-win32.c makes use of these items, which will then prevent it to built and work. I do have a very quick and dirty patch for it in 773299 (the only patch in there that is not committed at the moment), but I wonder whether there is any chance that I could do better with that, or that is the best I can do there. Any lights and pointers in this would be really appreciated. Having some private way to do embedded widgets *inside* gtk is much less problematic than exposing it as a general feature to all users, because we can then change it over time however we want. So, having some win32 hacks for gtkprintoperation sounds fine to me. However, the question is that over time as the way gtk+ renders is completely switched around, dropping things like non-toplevel GdkWindows, will we be able to keep the win32 embedding working? I'm not as sure about that part. > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a hate-fuelled crooked messiah who must take medication to keep him sane. She's a provocative bisexual museum curator fleeing from a Satanic cult. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gsk-render review
So, I had a quick look at the gsk-render branch. I don't really have much time for an in depth review, but here are some issues i saw: The first one is a detail in the gl renderer. As opposed to a regular 3d engine we will mostly be drawing things with z=0, with a lot of overdraw. So, we have to be very careful with z-overlap. In practice we're probably using something like the CSS z-index where in addition to the z value we have an order for rendernodes that share z. This order is implicit when we draw the tree in a simple fashion, but becomes more important when we start to do more advanced reordering during rendering (and we may also want to support explicit z-indexes in css). Right now the default rendering of opaque nodes is front to back. With the default depth test (LESS) this ends up doing the right thing. However, for the alpha nodes we render back-to-front, and I think the LESS depth test is wrong, is it not? I mean if you draw the back-most thing at Z=0, and then render another item at Z=0 it will not be drawn at all. Should it not be LEQUAL in this case? And when we start doing more interesting things such as reordering to minimize state changes then we need to explictily keep track of the node z-index and apply it as a depth offset. I think glPolygonOffset can be used for the z-index here, as its units is multiplied with "the smallest value that is guaranteed to produce a resolvable offset for a given implementation". How does servo handle this? The second issue I found was in the Gtk+ integration. In particular, the handling of queue_draw/resize. Traditionally, whenever you called queue_draw the affected area would be invalidated on the toplevel window and *everything* in that area would be redrawn from scratch. Currently this happens in the gsk-render case too, i.e. we re-render to a surface for each node. However, in an ideal world we would often not want to do this. For instance, if a button becomes focused we don't want to re-draw anything but that surface of the button, and then just re-compose all the other previously drawn surfaces. And in the case of a simple move of a widget we don't want to redraw anything at all, just recompose. Furthermore, there are many cases where we have/want to keep a pre-rendered version of a subtree of the widget tree. For instance, any place we have a opacity for a container and are currently pushing/poping an opacity group during the cairo-based rendering we really need to draw everything to a framebuffer and re-compose from that. In such a case, if nothing inside that framebuffer changed we want to avoid ever re-rendering it, and if something *does* change in it, we only have to re-render the framebuffer and then recompose anything outside it. I think we need to extend the api with which a widget can tell gtk how to redraw it. The sub-tree issues above is very similar to the ones we had when the pixel-cache was introduced. To handle that i added gdk_window_set_invalidate_handler() which can handle the catching and propagation of invalidation of child invalidations. We need something similar but on the render tree level. We also I think need to separate the calls to queue a compose of your level in the tree, and the marking of your cairo surface to be re-rendered. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Broadway backend fails with ”can't write to client”
On ons, 2015-10-07 at 10:21 -0400, Jay Jay Billings wrote: > > Everyone, > I am playing with the Broadway backend on Fedora 21 and I am getting > a ”can't write to client” error. It works fine with simple > applications like gedit, but it hangs and prints this error on more > complicated applications like Eclipse. Specifically, I get one good > click or tooltip access in Eclipse before it fails and, after a bit, > disconnects and prints a wall of these errors in the broadwayd shell. > Fedora 22 makes it three clicks before crashing. On that machine I'm > running gtk3.16.7. > As far as I could tell from the Broadway source code, this is a > generic error printed whenever the output stream can't be written. > Could anyone give me some more suggestions on how to fix this? I'm > willing to jump into the code too if you have some developer "getting > started" docs. "Can't write to client" basically means that the client process died, so we can't send any events to it. This problem seem to be on the client (that is the application, not the broadway daemon) side, so you have to debug the client instead. Having no idea of your particular problem I can still make a guess. It is likely that your more complicated apps (like eclipse) is trying to do something that is specific to the X11 backend, without actually verifying that the active backend is X11 (or verifying and bailing out). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scarfaced Amish hairdresser who must take medication to keep him sane. She's a hard-bitten thirtysomething vampire who can talk to animals. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMemVTable broken
On Fri, 2015-06-26 at 20:50 -0700, Jasper St. Pierre wrote: Yeah, we've all been sort of aware of this for some time. I've abused it to the fact where I know that malloc and g_new / free and g_free will *always* be the same since a specific glib version. I think removing all the code is fine. Patches for this here: https://bugzilla.gnome.org/show_bug.cgi?id=751592 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GMemVTable broken
So, I just tried to use the memory profiler in glib, and I crashes really early because the gobject constructor (gobject_init_ctor) calls g_malloc before main() is reached. This means g_mem_set_vtable() is impossible to use. I don't necessarily think this is all that bad. Honestly we should never have made it a vtable (one extra vfunc per malloc...) and instead do memory profiling etc the normal way, i.e. LD_PRELOAD something with malloc interceptors. Maybe we should just remove all this code and keep g_mem_set_vtable as a dummy function that prints a deprecation warning? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GNetworkMonitorNetlink question
The netlink code in GNetworkMonitorNetlink ignores all netlink replies
that are not from uid 0. It has done so since initial merging (bug
#620932), and there is even a comment in that bug from lennart that
describes how to use netlink:
e) for (;;) { recvmsg(fd, data...); if (SCM_CREDENTIALS.uid != 0)
continue; process(data...); }
This is breaking for me in user namespaces where uid 0 is not mapped (it
gets mapped to overflowuid), but just the user id. In this case we don't
even return an error. I.e this code:
sender = g_credentials_get_unix_user (creds, NULL);
if (sender != 0)
goto done;
Does not set retval to FALSE, which means we ignore all replies and then
wait forever as we never looked at the the final NLMSG_DONE message.
Is there really a risk of another user sending a message over netlink
here?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a scarfaced guerilla astronaut moving from town to town, helping
folk in trouble. She's a virginal hip-hop angel from the wrong side of
the tracks. They fight crime!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should we drop XP?
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! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a sword-wielding vegetarian househusband with nothing left to lose. She's a foxy paranoid research scientist with the power to see death. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should we drop XP?
On tis, 2015-03-31 at 22:41 +0200, Ignacio Casal Quinteiro wrote: Hey folks, so I was wondering if for 3.18/2.46 if we should drop XP. I think it would make our life easier and anyway why do we need to support something that microsoft is also not supporting? My opinion on this is that we should do this as soon as it is any kind of inconvenience to us to support XP. I.E. if we add some non-optional feature that doesn't work on XP. I don't think we necessarily have to drop existing XP code just because, let the existing support stay there until it no longer works. Its possible that this is true already, I've not done any Win32 work recently. If so, just drop it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an otherworldly neurotic cyborg living undercover at Ringling Bros. Circus. She's an enchanted green-skinned barmaid with an incredible destiny. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should we drop XP?
On ons, 2015-04-01 at 13:31 +0100, Emmanuele Bassi wrote: Hi; On 1 April 2015 at 13:26, Alexander Larsson al...@redhat.com wrote: On ons, 2015-04-01 at 14:24 +0200, Emmanuel Briot wrote: Just for reference, we've already had this discussion various times: https://mail.gnome.org/archives/gtk-devel-list/2014-December/msg00055.html https://mail.gnome.org/archives/gtk-devel-list/2013-October/msg00145.html Thanks for the pointers by the way. I understand now that in both threads, the proposal is to drop XP support for glib. Does this have any impact on gtk+ itself (it seems to me that none of the API proposed in the two links above are used by gtk+) ? If that's pure glib, I withdraw my comments since I only use glib through what part of it is used by gtk+. Other users might have different use, of course. Well, a future version of gtk+ may pull in a dependency on a later version of glib (which drops XP support)for some unrelated feature. This would then make it hard to use that version of Gtk+ on XP. If we want to keep GTK+ 2.24 working on Windows XP regardless of GLib's own support, then we could add a version check inside GTK+, or limit the build requirements, so that application developers still targeting Windows XP can know which versions of GLib can be used to build for that platform. I don't see the point though. If you're on gtk2, just use an older glib. The main reason to use a new glib is to be able to use a more recent gtk3 that depends on it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scarfaced dishevelled romance novelist who knows the secret of the alien invasion. She's a cold-hearted snooty museum curator with the soul of a mighty warrior. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should we drop XP?
On ons, 2015-04-01 at 14:11 +0200, Emmanuel Briot wrote: 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! On the other hand, there are industrial users out there who still haven't moved to more recent versions of Windows (for various reasons, possibly missing drivers for their old hardware, or because they have too many machines to upgrade easily). As a developer of gtk-based software, I'd like to be able to keep supporting them as long as possible. I understand the need to get rid of obsolete platforms, so perhaps it would be nice to have more details on which parts of the code can be improved once XP is dropped. Do you need to run the latest glib (and gtk+) on these systems though? Its not like the old versions of glib suddenly stopped working. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a benighted neurotic card sharp with a mysterious suitcase handcuffed to his arm. She's a sarcastic thirtysomething pearl diver living on borrowed time. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should we drop XP?
On ons, 2015-04-01 at 14:24 +0200, Emmanuel Briot wrote: Just for reference, we've already had this discussion various times: https://mail.gnome.org/archives/gtk-devel-list/2014-December/msg00055.html https://mail.gnome.org/archives/gtk-devel-list/2013-October/msg00145.html Thanks for the pointers by the way. I understand now that in both threads, the proposal is to drop XP support for glib. Does this have any impact on gtk+ itself (it seems to me that none of the API proposed in the two links above are used by gtk+) ? If that's pure glib, I withdraw my comments since I only use glib through what part of it is used by gtk+. Other users might have different use, of course. Well, a future version of gtk+ may pull in a dependency on a later version of glib (which drops XP support)for some unrelated feature. This would then make it hard to use that version of Gtk+ on XP. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an all-American Jewish barbarian who dotes on his loving old ma. She's a virginal hypochondriac socialite descended from a line of powerful witches. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should we drop XP?
On ons, 2015-04-01 at 16:48 +0300, Mart Raudsepp wrote: On K, 2015-04-01 at 14:33 +0200, Alexander Larsson wrote: On ons, 2015-04-01 at 13:31 +0100, Emmanuele Bassi wrote: Hi; On 1 April 2015 at 13:26, Alexander Larsson al...@redhat.com wrote: On ons, 2015-04-01 at 14:24 +0200, Emmanuel Briot wrote: Just for reference, we've already had this discussion various times: https://mail.gnome.org/archives/gtk-devel-list/2014-December/msg00055.html https://mail.gnome.org/archives/gtk-devel-list/2013-October/msg00145.html Thanks for the pointers by the way. I understand now that in both threads, the proposal is to drop XP support for glib. Does this have any impact on gtk+ itself (it seems to me that none of the API proposed in the two links above are used by gtk+) ? If that's pure glib, I withdraw my comments since I only use glib through what part of it is used by gtk+. Other users might have different use, of course. Well, a future version of gtk+ may pull in a dependency on a later version of glib (which drops XP support)for some unrelated feature. This would then make it hard to use that version of Gtk+ on XP. If we want to keep GTK+ 2.24 working on Windows XP regardless of GLib's own support, then we could add a version check inside GTK+, or limit the build requirements, so that application developers still targeting Windows XP can know which versions of GLib can be used to build for that platform. I don't see the point though. If you're on gtk2, just use an older glib. The main reason to use a new glib is to be able to use a more recent gtk3 that depends on it. If gtk2 stops working with a newer glib2, we've seriously failed with it's supposed ABI guarantees. That should not happen. However, a newer glib2 may not be buildable on XP, so it would break in that sense. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an old-fashioned dishevelled hairdresser from a doomed world. She's a chain-smoking mutant mermaid descended from a line of powerful witches. They fight crime! ___ 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
On lör, 2015-03-21 at 20:57 -0400, Ryan Lortie wrote: hi, On Sat, Mar 21, 2015, at 01:59, Jürg Billeter wrote: I would keep using O_CLOEXEC as it's as close as we can get to the behavior that should have been the default: don't implicitly inherit file descriptors on exec. Maybe there are applications out there that rely on correct file descriptor flags and directly call fork/exec. You could try to convince them to switch to GSubprocess (or work around the issue in their own fork/exec code). However, as I think we all agree that O_CLOEXEC is the best default behavior, I don't see why we should break these applications. This is probably the best counter-argument so far: since we all agree that the inherit-by-default behaviour is silly, we should try as much as possible to mitigate it. Overall I don't quite see what the argument is, other than the above which I agree with. Its a fact of life that O_CLOEXEC (and the threadsafe setting of it) is not universally available on the systems we support glib on. This means we *have* to close all open fds in e.g. g_spawn(), and no code can safely rely on it having been used on all open fds. In general, setting O_CLOEXEC is a nice thing to do, but doing so does not change the fundamental fact that you can't rely on it being set. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an ungodly misogynist librarian trapped in a world he never made. She's a plucky hip-hop doctor from out of town. They fight crime! ___ 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
On tis, 2015-03-31 at 09:48 +0200, Alexander Larsson wrote: On lör, 2015-03-21 at 20:57 -0400, Ryan Lortie wrote: hi, On Sat, Mar 21, 2015, at 01:59, Jürg Billeter wrote: I would keep using O_CLOEXEC as it's as close as we can get to the behavior that should have been the default: don't implicitly inherit file descriptors on exec. Maybe there are applications out there that rely on correct file descriptor flags and directly call fork/exec. You could try to convince them to switch to GSubprocess (or work around the issue in their own fork/exec code). However, as I think we all agree that O_CLOEXEC is the best default behavior, I don't see why we should break these applications. This is probably the best counter-argument so far: since we all agree that the inherit-by-default behaviour is silly, we should try as much as possible to mitigate it. Overall I don't quite see what the argument is, other than the above which I agree with. Its a fact of life that O_CLOEXEC (and the threadsafe setting of it) is not universally available on the systems we support glib on. This means we *have* to close all open fds in e.g. g_spawn(), and no code can safely rely on it having been used on all open fds. Actually, what *really* would help here in terms of kernel support would be a syscall that closed a range of fds. This could be very efficient in the kernel, avoiding the issues with the close-after-fork solution, but very easily put into use. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fiendish vegetarian master criminal with no name. She's an artistic mutant hooker with an MBA from Harvard. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_style_context_get()
On fre, 2015-01-30 at 05:51 +0100, Benjamin Otte wrote: Company yes Company when the frame clock triggers, we (1) recompute styles, (2) size_allocate everything pending, (3) draw mclasen whether css values are up-to-date at other points in the frame cycle should not be important mclasen except for those 3rd party users who randomly poke at style contexts... Company but it is important Company otherwise you get shrinking gnome terminals and white firefox text Company the gnome terminal case is actually rather complex to get right with the should not be important assumption Company because it needs to compute a bunch of values based on multiple different widgets Company and it needs to compute those before size allocation happens Company in short: It needs to happen in style_updated() at the latest - but which style-updated, when it depends on multiple widgets? What if we made style_updated its own phase in the frame cycle? Then we would run style update on all (invalid) widgets before we reach layout (size_allocate)? It seems a bit weird to me to request CSS values outside of either size_allocate or drawing. Is there really a sane usecase for this? The one thing that seems somewhat common/useful is if you want to render a widget to something like an offscreen or for an effect. But, what do you really want to draw in this case? The state of the widget hierarchy at a random point could be in a wildly inconsistent state (due to e.g. css changes or size changes). The three possible states that you would want to render is what was drawn last frame, what will be drawn next frame or what would be drawn if a size_allocate+draw cycle was initiated right now. The first is essentially impossible for us, since we don't store data from old frame state, the second is a bit painful if you want to draw something that is not an actual on-screen-frame (as it waits for the vblank, etc). So, the more realistic one is the last, but that requires us to be able to trigger the entire frame cycle at any point, in response to e.g. an out-of-frame gtk_widget_draw(). If we had something like this the gnome-terminal case could also use it to trigger a full relayout (including css validation and size allocation, but not the draw part in this case) before calculating the geometry hints (if that has to happen out of frame). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a short-sighted coffee-fuelled cowboy with a secret. She's a blind French-Canadian cab driver on the trail of a serial killer. They fight crime! ___ 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
On Thu, 2015-01-15 at 10:49 -0500, Morten Welinder wrote: My plan is to make it a guarantee of the API that both CREATED and CHANGED events will always be followed by a CHANGES_DONE hint. Great plan, but you cannot get that in a meaningful way. Think creat write mmap close # Further writes by way of the mapped region I don't think you can detect the end of that write. You can always queue a timeout-based changes_done. There is no guarantee that it will be after the last ever change. But you can still give a guarantee that every change will always be followed by at least one changes_done. Its a good thing in general to do these virtual change_done anyway, as it then automatically handles the logfile case where a file is written to now and then but never closed. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notes on wip/gdk-gl2
On sön, 2014-10-12 at 18:47 -0400, Owen Taylor wrote: Performance on my system is actually quite poor in at the moment, which seems at least to be pathological interactions with the system (i915, Fedora 21, Haswell.) I see 60fps with the default configuration of gdkgears for any windowed size of the window, but when I maximize I see the frame rate drop to 30fps, and when I make it fullscreen, I see it drop to 10fps. 'perf top' shows kernel memory allocation as the top functions, so it may be that the continual allocation of new render buffers is triggering the problem. I've done a lot of changes to how the glarea works and how the internal gl machinery works. I'm seeing a lot better performance than this, can you try it again and see how the current code performs? I also see rendering locked at a sub-multiples of 60fps - despite the fact that the rendering is additionally synchronized with the compositor frame clock. If I export vblank_mode=0 I see the expected non-locking behavior. How exactly do you see this? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notes on wip/gdk-gl2
On sön, 2014-10-12 at 18:47 -0400, Owen Taylor wrote: * It looks like there's a need to create a GdkGLContext for a window *before* the paint callback it is first used, since we use the existence of the internal paint GL context to know whether we are using GL for this paint; this is not documented. I think if you don't do this then the first frame will fall back to the software fallback, but next frame will work. I didn't test this though. * Does the paint GL context need to be always derived from the toplevel or nearest native ancestor of a GdkWindow? It looks to me like things might not work right if gdk_window_create_gl_context() is called on a client side subwindow. I've tried to make it work for all client windows, i.e. it should get the paint context for the nearest native window (the impl window). Its possible i missed this somewhere, if so we should fix that. * The approach of continually creating the render buffer may not give good enough performance, but if we do that, it's definitely desirable to create a minimal sized render buffer instead of one that's the size of the widget, since the cost of allocating a buffer gets larger the more pages that have to be allocated. We should probably keep the buffer allocated at least until the widget has not redrawn in a while. * What's the intended event handling for GtkGLArea? It seems like you'd have to put it into a GtkEventBox and handle events on the GtkEventBox - maybe GtkGLArea should have an event window? Yeah, we should probably add one as most gl areas will want some input (and its pretty lightweight if not). Will take a look at the other input later. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ scene graph, API deprecations
On mån, 2014-08-18 at 18:09 +0200, Sébastien Wilmet wrote: On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote: Because every time we try to clean up GtkTreeView, we break some random application. It's a widget that has twenty three gazillion use cases, and so we have to keep it a mess, because removing the mess means removing one use case, and we can't do that. So the problem is because GtkTreeView was developed as policy-free as possible. Now the new widgets are written with more policy, which makes the API easier to use, with a simpler implementation. As I see it there are two fundamental problems with GtkTreeView. First of all it has a model-view split, but there is no way to save any state in the view. For example, if the model has a char *icon_name column, then every time we draw a row we read the icon name from the column, set it as a property of the (one and only) pixbuf cell renderer, and then ask the cell renderer to draw itself. Now, since the cell renderer has no state it has to start from scratch each time, including reading the icon from *disk*. A few releases ago we added a cache for the icon theme, so we're not quite as bad as this any more, but it still happens if you have more different icons than the size of the cache. This doesn't only affect pixbufs. For instance if you have a tree with a lot of (mostly static) text you want to be able to cache pangolayouts for things like rendering of visible rows. The lack of a calculated state for the view also makes it hard to integrate with CSS for theming, as there is no view tree to do matching against. Secondly, it duplicates the entire size calculation machinery. Since we had no other way to make lists people started using TreeView for a lot of things, including more complex layouts. This lead to things like GtkCellAreaBox which essentially re-creates GtkBox but for cell renderers only. This kind of duplication is wasteful, hard to maintain and hard for users to understand. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: debugging broadway
On mån, 2014-03-10 at 23:06 +0100, Stefan Sauer wrote: On 03/10/2014 09:07 PM, Alexander Larsson wrote: On mån, 2014-03-10 at 15:14 +0100, Stefan Sauer wrote: hi, I wanted to see the broadway backend in action. Using gtk+3.8 I run broadwayd --address=ipaddr --port=8080 :5 and This has 8080 BROADWAY_DISPLAY=:5 GDK_BACKEND=broadway ./my-gtk3-app On the browser side, all I get is a blank window with a title containing broadway 2.0. Tested with chrome 33.0 and firefox 27.0. Firefox has this in the firebug console: NetworkError: 404 File not found - http://xxx:8084/socket-test; socket-test This has 8084 Cut and paste error? Yes :/ I'ved played a bit with the js debugger in the browers but still not success. Is there any order for launching stuff? Like 1) broadwayd, 2) connect from browser, 3) launch gtk-app? broadwayd first, then any order should work. Also, there is a keyboard handler handleCommands() on the js side. But pressing keys in the browser window seem to not show any effect. When I set a breakpoint on handleCommands() its not called, which makes me thing that the handler is not active. handleCommands() is not a keyboard handler. It handles messages from the broadway server from the websocket, and that is what fails to connect for you. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: debugging broadway
On tis, 2014-03-11 at 13:52 +0100, Stefan Sauer wrote: Okay, so I should not see these warnings? So the websocket connection is from the client to the server on the same port? Any ideas how I can narrow down whats the issue? Otherwise I'll need to build things from source and sprinkle printfs into the broadwayd code, I guess. Yeah, you should not see the 404s when connecting to the websocket, that means nothing will work... I don't really have time to help you debug it atm unfortunately. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: debugging broadway
On mån, 2014-03-10 at 15:14 +0100, Stefan Sauer wrote: hi, I wanted to see the broadway backend in action. Using gtk+3.8 I run broadwayd --address=ipaddr --port=8080 :5 and This has 8080 BROADWAY_DISPLAY=:5 GDK_BACKEND=broadway ./my-gtk3-app On the browser side, all I get is a blank window with a title containing broadway 2.0. Tested with chrome 33.0 and firefox 27.0. Firefox has this in the firebug console: NetworkError: 404 File not found - http://xxx:8084/socket-test; socket-test This has 8084 Cut and paste error? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Model/view ideas for GtkListBox/GtkFlowBox
On ons, 2013-10-23 at 13:16 +0200, Alberto Ruiz wrote: Hey Alex, I've been playing with this idea myself, have a look at this github repo[0], don't pay too much attention to the ListView widget, I'm pretty much replicating Gtk.ListBox for the sake of understanding how to implement such widget. I am trying to experiement with a scalable approach where you can have a large data set and a bound set of allocated widgets necessary to display in the scrolledwindow (and also to avoid new widget allocations while you scroll). Some people think this is a bit of an overkill so I don't want to get too deep into this discussion while it's still an experiment. Its not overkill at all. It is exactly what you want, and something e.g. Android always does for its views (its called view recycling there, google for it [1]). Basically you will have a set of row widgets created which are enough to fill the screen and then some. And when they go offscreen we reuse them (with new data) when scrolling in new rows. This means we can reuse widgets, avoiding using lots of memory for objects, and avoiding constant creation/destruction of objects. There is one thing that I'd like to discuss about the API that I designed there and it is the notion of the RowDelegate, which is an interface that requires GtkBin and points to a specific index (or row) of a GObjectSet (Data.List in the source). I don't think forcing each row to implement a specific interface (or even have a custom type) is the right thing. I mean, I think it will often be the case that you'd do this, but I also think something simple like a list with text should be able to just have a GtkLabel in the row and binding e.g. the name property on the model to the label property on the GtkLabel. I.e. first make the simple case simple (but efficient/smart) and then the complex possible. In a more complex situation you can create a custom row type with its own properties you can bind. Or, you can use class templates and bind model properties to child name (i.e. gtk_widget_get_template_child) + a property name on the child. Or in the most complex cases you can use GGBindingTransformFuncs or a raw callback that applies the model to the row. This kind of setup allows the view itself to handle a lot of the code that otherwise each RowDelegate would have to do, like track minimal model changes, only modifying the row widget properties that changed, queue changes updates to one-per-frame, etc. Also, the view needs to do part of this anyway for view-internal work like sorting and filtering based on the model and its changes. [1] Interesting links: http://stackoverflow.com/questions/15912999/recycling-views-in-custom-array-adapter-how-exactly-is-it-handled http://www.google.com/events/io/2009/sessions/TurboChargeUiAndroidFast.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Model/view ideas for GtkListBox/GtkFlowBox
More and more gnome apps are migrating to GtkListBox rather than GtkTreeView for lists, and we now have GtkFlowBox that replaces GtkIconView. These are nice for smaller lists, but with larger lists they are a bit heavy. We may want to look at optimizing whatever is possible, but at some point it makes sense to have a model/view split that allows us to have large models without having each item in the model be instantiated as a widget, both for performance reasons and ease of use. I've been thinking of ways to do this, and had plans to implement this, but atm I'm busy working on a side project, so I don't have time for this atm. I thought I'd write up a braindump of my ideas so that maybe someone else can look at it, or at least it won't be losts. So, the general idea is that we have a model, and we create and update row widgets from the model based on some kind of template. The new GtkBuilder class templates is an excellent example of how this could work. We then create widgets as needed as they are scrolled into (or near) view. One obvious problem with this is that we don't know the height of the rows until we have widgets for them, so the listbox probably has to be changed to implement GtkScrollable and do scrolling based on row-nr and average height rather than exact offsets. The model itself is a set of GObjects, where the data in the model is stored as GObject properties. This is very flexible, in that we have names (no more column nr shit) for the data that is easy to map to properties (like GBinding, possibly with some transform function) in the row widget template, as well as to generic sorting/filtering functions. Property notification makes incremental updates possible. The GProperty work being done will make it very simple to create such model objects, and make property lookups very efficient. Then we need to add a GObjectSet interface that has signals for when objects are added and removed to the set, which would be used as the model itself, but also as a property type for recursive models (i.e. trees). View updates on a model like this can be pretty efficient. We connect to the added/removed signals on the set and keep track of the items (and per-view info like selection status) in the view in a sorted filtered GSequence, then we connect to notify on all the model elements and whenever we get it we look up the GParamSpec to see how it affects the model (i.e. are we filtering/sorting/showing the changed property). If anything is affected we flag things in the view and request and update on the frame clock, so that we can minimally update the view structure and any visible widgets at most once per frame. I believe we should also have some sort property caches in the view objects. For instance any sort by string we should be monitoring changes to the corresponding property and keep a g_utf8_collate_key() or g_utf8_collate_key_for_filename() key up to date for fast comparisons. That should easily integrate with the update cycle above. We should also allow sorting based on object relationships. For instance, if we had a GObject *parent property that could be used to create a tree view if the view supported specifying that a child should be sorted directly after its parent. You can event do more complex structures like the twitter-style expand in-reply-to/replies before/after a tweet. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: non-Linux OSes
On mån, 2013-10-21 at 10:34 -0400, Ryan Lortie wrote:
hi,
GLib aims to work on a wide range of operating systems, but we have no
good story for ensuring that this is the case. Mostly we do things for
Linux and, if they are the sort of thing that may cause problems, we
also check that they work on Windows. We read manpages and make sure
that the functions we are using are in the proper POSIX specs, but this
is not always a fool-proof process.
We want to improve this situation.
Dan recently started by doing some patches to pull out ancient support
for OSes like OS/2 and BeOS.
We have brainstormed a list of platforms that we think that we want to
support and it looks like so: Linux, {Free,Net,Open}BSD,
(Open?)Solaris, HP-UX, AIX, Hurd, Darwin, mingw(32/64), MSVC.
By Darwin you mean OSX in general I assume?
I think this is a good idea, as it allows us to clean some things up,
and to know which features (like constructor support) that we can rely
on, etc.
I think the above list is a good start. But it is not good enough. We
also need to specify which versions of the above OSes, and which
versions of the compilers (especially important for e.g. msvc).
What about android? It runs linux, but its sufficiently different than
desktop linux to require its own testing.
Also, what about iOS? As per e.g.
http://stackoverflow.com/questions/5287960/compiling-glib-for-iphone:
Yes it can be built, (see:
http://stackoverflow.com/a/17733328/1856278) and there are
several Apps in the Appstore that uses it.
There is also the question of non-standard compilers (icc?).
llvm?
What we don't have are the resources to setup routine testing of GLib
against these target operating systems. Some of these operating systems
are not Free Software.
It seems to me that it should be possible to have virtual instances of
at least Linux (of various kinds), *Bsd, OpenSolaris, and Hurd running
in some VM farm setup with just some work. But ideally we should be
running copies of the non-free OSes too.
Which these are virtualizable on x86? I know OSX is virtualizable, but
there are licensing issues on non-apple hardware. Solaris is availible
on X86, maybe we can ask oracle for a few licenses for this (of course,
ideally we should be testing on sparc hw too). HP-UX is itanium and
pa-risc only i believe, AIX is PPC/s390 only. Maybe we could score a
power machine that can run VMs from somewhere, but s390/pa-risc/itanium
hardware sounds unlikely, maybe we can soft-emulate them?.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: flow box
On sön, 2013-09-29 at 22:28 -0400, Matthias Clasen wrote: I've pushed a flowbox branch, which adds a GtkFlowBox widget. It is a copy of the EggFlowBox widget that has been developed in the egg-list-box module for a while, which is in turn based on an earlier EggSpreadTable in libegg. I think the widget is more or less ready to land in GTK+. It has - accessibility - height-for-width - keynav - documentation - multi-selection including rubberband selection and autoscroll Multiple selection doesn't feel quite right. Nothing is ever unselected unless you click on an already selected cell, or shift-click range-select. Usually any selection modification clears the previous selection unless you held down some modifier. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: HiDPI stuff partially merged
- Original Message - On Wed, Jul 03, 2013 at 03:40:56PM +0200, Alexander Larsson wrote: I just merged the wip/window-scales2 branch. This means that gtk+ master has some level of support for window scaling. If you want to test this, you will still need the cairo branch at: http://cgit.freedesktop.org/~ickle/cairo/log/?h=device-scale (It still builds without it, but doesn't support scaling) Chris will merge this into cairo master and start a 1.13 version as soon as he manages to release the latest 1.12.x version, then this will not be needed. (Also, Chris talked about making cairo automatically inherit device-scale in cairo_surface_create_similar, if that happens we need to modify gdk_window_create_similar_surface to not do this.) And Chris finally has done so. Now available on the master branch at git://anongit.freedesktop.org/cairo Sweet, I just pushed an update to Gtk+ master to handle the change in device-scale inheritance. This means that Gnome 3.10 will be able to work in HiDPI out of the box if you build it with an snapshot of cairo! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
HiDPI stuff partially merged
I just merged the wip/window-scales2 branch. This means that gtk+ master has some level of support for window scaling. If you want to test this, you will still need the cairo branch at: http://cgit.freedesktop.org/~ickle/cairo/log/?h=device-scale (It still builds without it, but doesn't support scaling) Chris will merge this into cairo master and start a 1.13 version as soon as he manages to release the latest 1.12.x version, then this will not be needed. (Also, Chris talked about making cairo automatically inherit device-scale in cairo_surface_create_similar, if that happens we need to modify gdk_window_create_similar_surface to not do this.) I also have some patches to add automatic detection of hidpi screens and enable the scale at: https://git.gnome.org/browse/gsettings-desktop-schemas/log/?h=wip/window-scales https://git.gnome.org/browse/gnome-settings-daemon/log/?h=wip/window-scales Also, gnome-shell is pretty broken when Gtk+ is running in scaled mode, so there is this badhack I use to make gnome-shell work with the above: https://git.gnome.org/browse/gnome-shell/log/?h=wip/window-scales Highres css assets require a branch atm: https://git.gnome.org/browse/gnome-themes-standard/log/?h=wip/hidpi Running with all the above on my Chromebook pixel things seems to mostly work. There are some open issues: * clutter doesn't respect the window scaling, so the gl rendering is too small. * No support at all for using larger cursors or DnD icons * As I said above, gnome-shell doesn't handle scaling at all I'm leaving for vacation after friday and will be back for Guadec... I might be around now and then, but not much. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Attention: State propagation changed in master, themes may need changes
So, I just landed GtkListBox in Gtk+ master. Its essentially a slightly evolved version of EggListBox. One of the main differences compared to EggListBox is that it has a specific row widget GtkListBoxRow which is the only thing that can be a child of a GtkListBox (well, if you add anything else one will be inserted for you). One of the important reasons for this is that you then get a reference to the row in the css system, so that you can e.g. set the GTK_STATE_FLAG_SELECTED on it. This was a problem with EggListBox where the selected state was just temporarily set during the drawing of the row background, which meant child widgets could not match on this and thus we could not change the color of the text in a selected row to match the selection color. However, setting the state flags on the row widget exposed a weakness in the Gtk+ theming system. Gtk+ propagates most state flags (including selected, active, prelight, all used on listbox rows) to all children. This means that if a row with a button is selected, the label inside the button will look selected (white text on blue). And if you click on the row the button looks like its being activated (clicked). This is a general problem in Gtk+ for all kind of container widgets that are also interactive, and the fix (now in master) is to not propagate these states. In fact, the only states that are now propagated to child widgets are INSENSITIVE and BACKDROP. This may seem weird, as the state of a parent needs to be able to affect a child (e.g. the label color in a selected row), but it is not so strange because we use CSS to theme things, and CSS uses other ways to inherit from a parent. For instance, the color property is by itself inherited by default, so if you just set the color on the row it will automatically be applied to the label child. And if that is not enough you can match on the parent state using CSS selectors. In fact, most things just seems to work with current adwaita. However, it is possible some things are broken, so please everyone be on the lookout for things that look weird. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: wip/hires-icons
On tor, 2013-05-16 at 18:08 +0200, Carlos Garnacho wrote:
First of all, I'm aware this partially collides with Alex's work[1], but
on this branch the backing surface scale details have just been sorted
out for the Quartz backend, so the meat in this branch can still greatly
benefit from his work on X11 and Wayland, plus it'd mean plugging less
holes to get the right icon scale at render time.
I'm aware of this, and in fact i stole the basic scale_factor commits
for my work on wayland hidpi. I think that part is basically right
as-is, although there were some implementation issues:
gdk_window_get_scale_factor() should report the scale factor of the
closest native window, not the toplevel. I don't think this is
necessary any practical difference (certainly not for quartz or wayland
which don't do native subwindows), but it seems more right:
diff --git a/gdk/gdkwindow.c b/gdk/gdkwindow.c
index e4f4e51..f321baa 100644
--- a/gdk/gdkwindow.c
+++ b/gdk/gdkwindow.c
@@ -10604,7 +10615,6 @@ gdk_window_get_scale_factor (GdkWindow *window)
if (GDK_WINDOW_DESTROYED (window))
return 1.0;
- window = gdk_window_get_toplevel (window);
impl_class = GDK_WINDOW_IMPL_GET_CLASS (window-impl);
if (impl_class-get_scale_factor)
gtk_widget_get_scale_factor() Should always report the GdkWindow scale
factor if the widget is realized:
diff --git a/gtk/gtkwidget.c b/gtk/gtkwidget.c
index 123f396..08d86d7 100644
--- a/gtk/gtkwidget.c
+++ b/gtk/gtkwidget.c
@@ -9932,13 +9932,13 @@ gtk_widget_get_scale_factor (GtkWidget *widget)
g_return_val_if_fail (GTK_IS_WIDGET (widget), 1.0);
+ if (gtk_widget_get_realized (widget))
+return gdk_window_get_scale_factor (gtk_widget_get_window
(widget));
+
toplevel = gtk_widget_get_toplevel (widget);
if (toplevel toplevel != widget)
return gtk_widget_get_scale_factor (toplevel);
- if (gtk_widget_get_realized (widget))
-return gdk_window_get_scale_factor (gtk_widget_get_window
(widget));
-
/* else fall back to something that is more likely to be right than
* just returning 1.0:
*/
For me, with my wayland HiDPI work I need this in order to create a
surface of the right scale for scrolling. If this is not done then
when the window moves from a display with no scaling to one that has
it looks really bad. Doesn't Quartz need this too?
diff --git a/gtk/gtkpixelcache.c b/gtk/gtkpixelcache.c
index 9b2f1d8..882dbcb 100644
--- a/gtk/gtkpixelcache.c
+++ b/gtk/gtkpixelcache.c
@@ -38,6 +38,7 @@ struct _GtkPixelCache {
int surface_y;
int surface_w;
int surface_h;
+ double surface_scale;
/* may be null if not dirty */
cairo_region_t *surface_dirty;
@@ -159,7 +160,8 @@ _gtk_pixel_cache_create_surface_if_needed
(GtkPixelCache *cache,
cache-surface_w view_rect-width ||
cache-surface_w surface_w + ALLOW_LARGER_SIZE ||
cache-surface_h view_rect-height ||
- cache-surface_h surface_h + ALLOW_LARGER_SIZE))
+ cache-surface_h surface_h + ALLOW_LARGER_SIZE ||
+ cache-surface_scale != gdk_window_get_scale_factor (window)))
{
cairo_surface_destroy (cache-surface);
cache-surface = NULL;
@@ -178,6 +180,7 @@ _gtk_pixel_cache_create_surface_if_needed
(GtkPixelCache *cache,
cache-surface_y = -canvas_rect-y;
cache-surface_w = surface_w;
cache-surface_h = surface_h;
+ cache-surface_scale = gdk_window_get_scale_factor (window);
cache-surface =
gdk_window_create_similar_surface (window, content,
And in general, we probably need a signal that you can watch for to
get notified of scale factor changes. I propose that the backends send
a spurious configure event in this case, which GtkWindow can catch and
see if the scale has changed. Then it can emit a signal that child
widgets can listen to. Also, obviously a scale change has to invalidate
the whole window for redrawing. We possibly also want to queue a resize,
because the font metrics may have changed, depending on how you're
rendering.
This branch doesn't precisely reinvent the wheel, there's just a few API
additions to current components to have this work as seamlessly as
possible. As choosing an icon must be postponed till rendering time, the
preferred way to hold this information is GtkIconSet and GtkIconSource,
as these already do a few things we want here:
* It may already hold multiple sources for an image
* GtkIconSize works as a scale-independent size abstraction
This has implied making GtkIconSets more prominent, so the matching
properties have been added to GtkEntry and GtkCellRendererPixbuf.
GtkIconTheme has been regarded as a lower level file-pixbuf abstraction
and mainly a few *_for_scale() calls have been added there so
GtkIconSets can resolve rendering to the bes3t pixbuf.
Ugh. I hate GtkIconFactory. Mainly due to the GtkIconSize abstraction.
Any time i use it I have to fight that crap, because what you really
*do* want is a (possibly
Re: New drawing/scrolling model
On fre, 2013-05-03 at 21:59 -0400, Matthias Clasen wrote: On Thu, May 2, 2013 at 2:40 PM, Alexander Larsson al...@redhat.com wrote: I've tried a bunch of apps and most things seem to work. Currently I know of two problems: I've gone through gtk3-demo and our other test programs with this branch, and could only find one noticable breakage: The GtkStack crossfade transitions seem to be somewhat messed up with the branch. If you look at the example in the second page of gtk3-widget-factory, you'll notice how the colors of the cube change before it starts to fade out. This is not happening with master. I fixed this. It was a bug in GtkStack where it didn't check gtk_cairo_should_draw_window() so it ADDed the crossfaded surface twice creating the weird colors. This wasn't a problem before as then the alpha/opacity-group case only called draw() once for each widget (rather than once per gdkwindow), but that is really not quite correct. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New drawing/scrolling model
On fre, 2013-05-03 at 21:59 -0400, Matthias Clasen wrote: On Thu, May 2, 2013 at 2:40 PM, Alexander Larsson al...@redhat.com wrote: I've tried a bunch of apps and most things seem to work. Currently I know of two problems: I've gone through gtk3-demo and our other test programs with this branch, and could only find one noticable breakage: The GtkStack crossfade transitions seem to be somewhat messed up with the branch. If you look at the example in the second page of gtk3-widget-factory, you'll notice how the colors of the cube change before it starts to fade out. This is not happening with master. This breaks with GdStack too. I pushed a fix for it. Anyone using it in gnome 3.8 apps should update if they do a new 3.8.x release. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
New drawing/scrolling model landed
I just merged the wip/simple-draw4 branch with master. It seems to work pretty well now. Open issues i know of: Anything using GdStack to do crossfades will show some weird coloring during the fade, these apps should upgrade to the latest libgd (or ideally to GtkStack). The gnome-cc background panel uses gdk_cairo_create() rather than use the passed in cairo_t in draw(), so it looks weird in the crossfade. There is some things left to do for this, some we really need to do before 3.10 is released: * Make GtkIconView use GtkPixelCache * Make GtkTextView use GtkPixelCache Some are optional but may be interesting: * Allow some kind of hinting to GtkPixelCache so that e.g. we always fit full rows in a GtkTreeview. This is nice as there is some per-row drawing overhead which we then avoid when scrolling. * GtkViewport generally always has a transparent background, but it often happens that the child does not. Atm this means that we render the pixel cache as RGBA starting at transparent and then composite it using OVER. However, in the case of a child with a non-transparent background (like a white EggListBox) we really would want to know that the child is opaque so that we can just use a RGB buffer and SOURCE rendering. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New drawing/scrolling model
On fre, 2013-05-03 at 00:03 +0200, Søren Sandmann wrote: Alexander Larsson al...@redhat.com writes: * Try a tile-based approach for GtkPixelCache to avoid having to do a same-surface copy (usign an intermediate surface) when scrolling the cache. An alternative to tiles is to keep track of an origin within the surface: ++--+ | Bot R | Bottom left | || | +O--+ | Top R | Top left | || | || | || | || | || | || | || | ++--+ with the contents of the surface addressed modulo width and height. Scrolling is then just a matter of moving that origin, but copying from the surface may require four separate blits. Similarly, rendering to some rectangle may have to be split into four separate operations. Yeah, a 2d circular buffer. I've thought about this and its clearly doable, although somewhat of a nightmare to handle all the cases. t still has some overhead that it shares with the tiled version though, we need to traverse the scenegraph multiple times, which isn't super cheap currently. It would be nice it cairo could let us stitch together a surface made out of multiple subsurfaces, then we could avoid such overhead. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New drawing/scrolling model
On tor, 2013-05-02 at 18:20 -0400, Paul Davis wrote: On Thu, May 2, 2013 at 6:03 PM, Søren Sandmann sandm...@cs.au.dk wrote: Alexander Larsson al...@redhat.com writes: * Try a tile-based approach for GtkPixelCache to avoid having to do a same-surface copy (usign an intermediate surface) when scrolling the cache. An alternative to tiles is to keep track of an origin within the surface: ++--+ | Bot R | Bottom left | || | +O--+ | Top R | Top left | || | || | || | || | || | || | || | ++--+ with the contents of the surface addressed modulo width and height. Scrolling is then just a matter of moving that origin, but copying from the surface may require four separate blits. Similarly, rendering to some rectangle may have to be split into four separate operations. this is where trying to be too generic hurts. a given widget knows its aspect ratio. for things that are short and wide, their pixel cache will consist of a set of full-height, partial-width surfaces. for things that are tall and narrow, their pixel cache will consist of a set of full-width, partial-height caches. for things that are short and narrow, their cache will consist of a single surface. for things that are wide and tall ... well, they're on their own ... This is not really a problem the pixel cache knows the size of the canvas and the viewport so it will automatically not pick an unnecessarily wide/tall offscreen surface. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New drawing/scrolling model
On fre, 2013-05-03 at 05:52 -0400, Paul Davis wrote: On Fri, May 3, 2013 at 3:02 AM, Alexander Larsson al...@redhat.com wrote: things that are wide and tall ... well, they're on their own ... This is not really a problem the pixel cache knows the size of the canvas and the viewport so it will automatically not pick an unnecessarily wide/tall offscreen surface. if true, then i don't see where the two dimensional multi-surface blit issue arises. you may need to blit several surfaces along one axis, but that is sort of the definition of the pixel cache. Not sure which issue you mean. The current code doesn't do any kind of tiling or circular buffers, all it does is keep an offscreen of the visible area and then some extra (64 pixels). As long as we're scrolling less than 64 pixels from what we drawn the first time all we have to do when scrolling is to copy a different area of the offscreen surface to the window. However, when we scroll past the 64 pixels we currently do a copy on the offscreen surface to itself of the area that will still be visible, and then we render the rest. This copy is an issue, since: a) It is a self-surface copy so we have to use an intermediate surface to do it b) Its not technically necessary, there are alternatives like tiles and circular buffers that avoid this copy Of course, the alternatives have a cost too. For once they make the code more complicated, but they also will render the widget hierarchy multiple times to the different tiles / parts-of-circular-buffer, and for each time we have to traverse and draw all the children of the scrolled container. For some containers this is probably ok, like the treeview as it can quickly find the affected rows to redraw, but for others its more of a problem. For instance GtkTextView only keeps a cache of the latest 2 rendered PangoLayouts, so it may relayout the text for each rendered tile. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
New drawing/scrolling model
I've just pushed the wip/simple-draw4 branch which is the latest version of my work trying to simplify and modernize the Gtk drawing machinery. Its now in a state where I think its time to discuss the merging of this. The very first commit in the branch makes gdk_window_move() and gdk_window_scroll() very dumb. Previously it tried to copy as much as possible of the existing pixels and only invalidate the areas that were previously not visible. Now it just invalidates the entire scrolled area and redraws it. This may seem a bit crazy and slow, but in fact its just the first step in making the gdk drawing model more modern. Doing scrolling by same-surface copying is an old technology has some problems in the modern world. First of all, on modern hardware a same-surface copy doesn't work very well (for technical reasons). In fact, the operation is a no-op in the wayland backend atm. Secondly, in a more modern scene graph like in recent gtk3 most windows have alpha pixels and render over the window background rather than each window rendering its own opaque background, so scrolling via copy doesn't work. So, the branch continues with deleting lots of very tricky code inside gdk where does things like figuring out the cases where we can apply the copy optimization, and handling async exposes from the xserver racing with copy-area of the same region from the app. A more modern way to do scrolling is to keep an offscreen buffer for the content inside the scrolling region, covering what is currently visible in the viewport plus a bit more. Then when we draw the window we just draw the buffer in the right place, making scrolling very fast. Although if you scroll to far we have to render a new piece of the offscreen buffer. To do this kind of scrolling a container needs two things, a way to get told when a child needs redrawing so that we can make our cache dirty, and a way to retarget rendering the children to the offscreen buffer. We add some gdk API (gdk_window_set_invalidate_handler) for the first, but the second is a bit more complex. Right now rendering is done in many separate phases, one per GdkWindow where for each GdkWindow there may be several non-window widgets (and each widget may have several windows too). The branch completely redoes this so that Gtk+ only ever handles expose events on native windows (i.e. generally toplevels only) and then renders everything inside the ::draw signal handler of the toplevel widget. In order to maximize backwards compatibility we still call draw() multiple times on multi-window widgets, with the right clipping set up and the right window backgrounds rendered, however, there are still some minor differences. For instance, we expose primarily in widget order whereas we previously exposed in window order (although for windows in the same widget we respect the window order), but this is rarely a problem because intra-widget window order in gdk is hard to control anyway due to realize being called in unexpected places. With this in place the branch then does some further simplifications and then adds fast scrolling support to GtkViewport and GtkTreeView via the new GtkPixelCache helper object. I've tried a bunch of apps and most things seem to work. Currently I know of two problems: The control-center background panel calls gdk_cairo_create() inside the draw() handler, which draws directly to the window rather than the passed in cairo_t. This works in a sense, but the rendering is then unaffected by the cairo_push()/pop() that the stack uses for crossfading, so the crossfade effect breaks. This could possibly happen in other cases, but it seems like it is pretty uncommon (I didn't find any other problematic use in all of Gnome). The control-center display panel does this weird thing where it draws areas using cairo, and then reads it back to use as input regions. This code assumes that the coordinates on the cairo_t when converted via cairo_user_to_device() is in the coordinate space of the widgets windows, whereas it is now in the coordinate space of the toplevel. This makes the input regions offset by the position of the widget making it hard to click/drag them. This is a pretty weird thing to do, and i don't expect we'll run into other apps doing the same thing. IMHO we can just land the branch and fix these issues inside the control-center. Its a minor incompatibility change, but I think its still worth it. There is still some further work we may want to work on after the branch lands, in case someone wants to help out: * Port GtkIconView to GtkPixelCache * Port GtkTextView to GtkPixelCache * Have some way to hint a GtkPixelCache so that we e.g. always render an entire treeview row or textview paragraph when painting, to avoid multiple setups for drawing it when scrolling. * Try a tile-based approach for GtkPixelCache to avoid having to do a same-surface copy (usign an intermediate surface) when scrolling the cache.
Re: New drawing/scrolling model
On Thu, May 2, 2013 at 2:40 PM, Alexander Larsson al...@redhat.com wrote: . Secondly, in a more modern scene graph like in recent gtk3 most windows have alpha pixels and render over the window background rather than each window rendering its own opaque background, so scrolling via copy doesn't work. which really touches on whether simple-draw5 or some future WIP will just use a scene graph for everything anyway ... simple-draw4 targets 3.10, its not very large: 23 files changed, 1274 insertions(+), 2212 deletions(-) But, the long term for Gtk4 is to move to a scene graph based on clutter. and finally, does simple-draw4 attempt to work hard on behalf of particular widgets, or is complexity left to the widgets? i think it is far preferable to go the latter route, although there may be a small cost of duplicated effort. All complexity is left to the individual widgets, although there is a helper object to share code. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New baseline branch, review wanted
On tis, 2013-03-26 at 16:56 +0100, Alexander Larsson wrote: I've done a bunch of work on the baseline stuff and rebased it into a nice branch called wip/baseline3. Its got the core working with a bunch of widgets converted. I pushed some minor details that cosimo pointed out, and this solution to the vfunch issue: https://git.gnome.org/browse/gtk+/commit/?id=308aebff9daa863ea4144ec2b474ea021995b47f Which I believe will work. The remaining issues are GtkComboBox ( cell renderers in general) and the non-property aspect of gtk_grid_set_row_baseline_position. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
New baseline branch, review wanted
I've done a bunch of work on the baseline stuff and rebased it into a nice branch called wip/baseline3. Its got the core working with a bunch of widgets converted. The only interesting widget that lacks baseline support (imho) is GtkComboBox. But that one is hard due to it using GtkCellArea co. I'd rather not add baseline support to cell renderers... There is a new GTK_DEBUG flag called baselines, so if you want to try this out, do: GTK_DEBUG=baselines tests/testbaseline There are however some open issues: * I added a new vfunc called get_preferred_height_and_baseline_for_width which is the basic baseline supporting size request. The core code will call this all the time now, but there is a default implementation that calls the old methods, which should keep old widgets working. However, when I add baseline support to some existing classes i override the default implementation. This means that widgets deriving from these classes (say e.g. GtkButton) that override the old size request vfuncs (say get_preferred_height), will break. We will keep calling the baseline supporting version of the baseclass. I'm not sure how to fix this. I could add some per-type flag for baseline support such that we only use get_preferred_height_and_baseline_for_width if this flag is set. That would mean such old widgets keep working. However, it also means that you *must* always set this flag for all derived classes, even for things where baseline support was implemented from the start, which seems kinda bad. Not sure what the best approach here is... * GtkGrid has a new per-row property, gtk_grid_set/get_row_baseline_position. This is neither a normal property or a child property, which means its not really nicely bindable or usable as construct properties in e.g. GtkBuilder. Is there a good way to handle this? Other than this I think this branch is in a pretty good state. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Baseline alignment WIP
I just pushed the wip/baseline branch to git. It contains the initial steps towards adding baseline alignment in gtk+, by extending the size request and size allocation framework with: * A way to report a baselines corresponding to the minimum and natural heights * A way to allocate the baseline of a child widget in a baseline aware container * A way to flag widgets that they want to be baseline aligned It also contains baseline support for label, button, alignment and horizontal boxes which works well enough for this test: http://people.gnome.org/~alexl/baseline.png I started working on the vertical box implementation, where we would align the baseline to the baseline of the first child that had GTK_ALIGN_BASELINE valign. This is useful for e.g. layouts like this: +---+--+ | | [IMG] | | | [IMG] | | Label|...[Entry] [IMG] | | | | | +--+ | | | . Where we want the label in the left to align with the first text in the vbox on the right side. Conceptually this doesn't seem very hard, and i got the size request part done easily. However, the size_allocate() implementation for the case where a particular child widget is supposed to be on a specific position is very complicated due to all the complexity of boxes (pack start/end, homogenous, natural distribution of height, etc) so I gave up for now. However, I think implementing baseline support for things like entries, rows-in-GtkGrid, GtkButtonBox, etc should be pretty easy and might be an interesting excercise for other people who try out this branch. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Baseline alignment ideas
On ons, 2013-02-27 at 17:47 +0900, Tristan wrote: Ah, I think I understand your question better now. Use a natural allocation process similar to gtk_distribute_natural_allocation(): http://git.gnome.org/browse/gtk+/tree/gtk/gtksizerequest.c#n599 Instead of looping over widget size requests, provide a normalized value for the minimum and natural requests above and below the children (after allocating the absolute minimum height). o Start by giving equal minimum above height to all children and equal minimum below height to all children Well, this just means give each child their minimum height initially. o Distribute extra allocated space above and below equally until one of the sides (above or below) reaches natural allocation But, this is where I don't really follow. In practice all we have are child widgets which we can ask for what would the baseline be if you had this height (and width, since its always fixed by now). From this we want to decide the *total* height of each child. How do we assign 5 pixels above the baseline based on this? All we can do is give the child more total height (via gtk_widget_size_allocate), we have in general no control of where that height will go. The child might be expandable both above and below its baseline, but how can we tell it to only grow above? The only way I can see is this iterative algorithm. Its based on the fact that as we add height to each child it may appear above or below the baseline, and in the worst case of two children growing on different sides the container height will grow by double of what we add to the children. So, we do something like: 1. allocate each child its own min height, calculate baseline and total height 2. calculate the missing height to the allocated height 3. assign half the missing height to each child, this will at *most* grow you to the allocated height. 4. Recalc the missing height, if 0, goto 3 This will take log2 (assigned_height - min_height) steps and will result in a state where there is at least one child we can't give more height as that would make the total height larger than the allocation. However, there might still be some children that can safely expand. To fill those we'd have to for each child try to grow it as much as possible without affecting the total height. This can be done with a similar loop, starting with adding MIN(space above widget, space below widget) in a loop until this is 0. We then hit the top say, but then we need another loop to see if giving more height means it extends towards the bottom. Each try here is a full size request, including w4h, h4w, children with baselines, etc. This just strikes me as *way* too expensive. A simpler approach would be to only ever look at the natural size request for baseline aligned children, and always allocate size as per this, never ever growing any children. Then we can top/bottom/center align the whole group of baseline aligned children, but never FILL it. This is trivial to calculate, but are there cases where this will not be enough? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Baseline alignment ideas
On ons, 2013-02-27 at 21:22 +0900, Tristan Van Berkom wrote: How do we assign 5 pixels above the baseline based on this? All we can do is give the child more total height (via gtk_widget_size_allocate), we have in general no control of where that height will go. The child might be expandable both above and below its baseline, but how can we tell it to only grow above? Interesting... taking your previous example of HBox with widgets A, B, B, and D... let's consider that A B is in VBox1 and B D is in VBox2 What you are asking (I think) is how can we determine that VBox2 can only grow /below/ and that VBox1 can only grow /above/. Is this correct ? Mostly, although there are more complexities. It may grow on both side, but to different extents and with different speeds. For instance, imagine a multi-line label that is ellipsized and has the baseline setting as GTK_LABEL_BASE_LINE_IS_LAST_ROW. At any point it shows N rows with the baseline at the Nth row, and if you add height it will add empty space below the Nth row, but then when you suddenly fit another row you'll get the baseline at the N+1th row and the height the was previously blow now got moved to above the baseline. I think this conversation needs a little bit more context (as to how precisely you plan to layout the groundwork APIs for this), but here's what I would envision: I think that HBox has the responsibility to 'request and set the baseline' of it's contents (being VBox1 VBox2) Thats not what I was thinking, but that does seem to make this more doable. However, this means that *all* implementations of size_allocate must respect the baseline when allocating itself. Thats very different from how todays existing widgets work, and a radical break of API. The model i was expecting is the current one where widgets do whatever they do in gtk_widget_size_allocate() but can report where this would put the baseline. Of course, in practice container widgets outside of gtk+ are not that common, so its possible that we could make sure the gtk+ ones did handle an extended form of size allocation, which would let us do baseline alignment in most cases. Of course, implementing size allocation of e.g an ellipsizing label like the above example with a pre-chosen baseline will be complicated and probably need new PangoLayout APIs... I'm pretty sure this approach work's in theory, but there's a big 'gotcha' in play... which is the intrusive 'halign'/'valign' properties and any properties which are implicitly calculated by the -adjust_size_request() and -adjust_size_allocate() vfuncs. Which means the whole thing breaks down if either VBoxes have a valign property that != GTK_ALIGN_FILL or that margins or border_width are set... this is a hard problem to figure out too... it might require that widgets retain access to the full allocation given them by their parent, instead of the final allocation stored after adjustments are made. I'm not sure this is a problem. valign will in this case be BASELINE, or we would not do baseline alignment of the child at all. The margins and borders could well be done automatically like now, as long as they correctly modify the baseline that the child get, i think... Finally, it's worth noting (I'm sure you're already aware) that minimum natural preferred_height_for_width() will hardly ever differ (they will only differ for vertically rotated text, or perhaps some GtkWrapBox which is oriented to wrap from top to bottom). Ellipsized multiline strings is another case. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Baseline alignment ideas
One of the main layout features we're badly missing atm is baseline alignment. I spent some time looking at this recently but I bumped into some problems. I'd like to bring this up for discussion in the hope that we might figure out a solution to my problems. First, let me define what i mean by baseline layout and the API I expect it to have. Every widget has a single baseline, which is an offset from the top of the allocation to the baseline. Some layouts (such as e.g. multi-line text) have multiple possible baselines, but this is outside of the common gtk+ api and each widget gets to decide which one to use, via some per-widget API. We add a new GtkAlign element, GTK_ALIGN_BASELINE, which when not supported does the same as CENTER, but in containers that support baseline alignment we align all the children with BASELINE up so that they all have the baseline at the same y coord. Additionally we need a single setting for the container itself that decides how to align the whole group of baseline aligned widgets (i.e. do we put the baseline alignment widgets at the bottom or at the top? An example hbox layout could look like with baseline at botttom: +---+ |+---+ | || START | | |+---+ | | ++| | +---+ | CENTER || | +---+| | ++| | |--BASE-||-BASE--|+---+ | | | |+---+| END | | | +---+ +---+ | +---+ Now, back to the problem. Consider implementing size request/allocation for the container above. We can start with the min width, asking each child for min width and summing that. Then we ask for min height for that width and for the baseline at that width. We can thus simply calculate the min and natural size requests and their corresponding baseline. The problem comes later, when we get the final size allocation for the container. Its easy to distribute the widths, but if the final height is not the same as the min/natural request, how do we distribute the height among the baseline aligned children such that the total height after we baseline align them fits in the assigned height? Since the baseline position depends (non-linearly) on the exact height we assign to the child, and the total size depends on the baselines this seems circular, and I can't see any way to calculate this other than in some iterative fashion. For instance, if you have two children with the baseline at the top, then all extra space can be assigned to each child. However, if one has the baseline att the bottom you need to give each half the extra height. I don't really see any way to solve this generically. But maybe we can somehow limit our baseline support so that this works? For instance, we could always request the naural size for baseline aligned widgets and never grow them? Would that be enough in practical use? I dunno... Ideas wanted... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Baseline alignment ideas
On tis, 2013-02-26 at 10:58 -0500, Matthias Clasen wrote: On Tue, Feb 26, 2013 at 9:30 AM, Alexander Larsson al...@redhat.com wrote: Ideas wanted... I think you basically have to split the height that is returned for minimal or natural size into an overlength/underlength pair. Then you can sum them up separately in containers that support baseline alignment. In containers that don't, you'll always just use the total height (which is the sum of the two). Would that work, or am I overlooking something ? Yeah, thats the way you implement size *request*. The problem comes when you get to the allocation phase. Let me give a simple example. We're laying out a hbox with two child vboxes, each with a label and some other widget. Like this: +- HBox --+ |+---+| || || || A|| || || |+---+ ++ | || B| |B | | |+---+ ++ | | || | | |D | | | || | | || | | ++ | +-+ The labels B are identical, but packed in different order in the vboxes. To make things easy, lets say all widgets are 100 px wide. Then: min height nat height baseline A: 10 20 B: 20 20 10 C: 20 30 Its quite obvious that the min height of the hbox is 10+20+20 == 50, the natural height is 20 + 20 + 30 == 70px, and the corresponding baselines are at 20 and 30. And the width is 200 px. So, we report this is size_request. Now the size machinery happens and we get called with the final size of the hbox. It is to be 200x60 pixels. Now, what size should we allocate to the children? At least we should fulfill the minimum request which is 50 px tall. But then we have an extra 10 pixels to distribute. But, how do we distribute it? Whenever we add size to some particular child that will affect the baseline of that child in some complex way. For instance, in this case as the two children point in different direction we should probably give each child 5 pixels more each which gives a total height of 60. But if the order of the two children were the same we should give each child 10 pixels, which would then give us 60 pixels. Now repeat the same for arbitrarily complex dependencies on the child baseline position based on its height... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Baseline alignment ideas
On ons, 2013-02-27 at 01:18 +0900, Tristan wrote: My thoughts are that, when performing get_preferred_height_for_width(), you need some virtual allocation logic like such that is found in gtkbox.c (when we are requesting in the 'uncomfortable/opposing' orientation): a.) Calculate how much width exactly would be given to each child b.) Calculate height-for-width of each child c.) Report the MAX of all child heights. Now with baselines, this becomes slightly more complex, during the h4w request phase you need to replace the above 'c' with something that aligns the requested baseline(s) for all children, and requests a little bit more height in order to logically fit all children into that height (which is dependent on the provided width). It'd be something like this: a.) Calculate how much width exactly would be given to each child b.) Calculate height-for-width of each child c.) Calculate the baseline-for-width of each child d.) For each child, divide the height in two parts, one above baseline and one under. e.) Report the MAX (above baseline) + MAX (below baseline) of all child heights. But this is not really the complex part. For instance, if you have two children with the baseline at the top, then all extra space can be assigned to each child. However, if one has the baseline att the bottom you need to give each half the extra height. I don't really see any way to solve this generically. But maybe we can somehow limit our baseline support so that this works? For instance, we could always request the naural size for baseline aligned widgets and never grow them? Would that be enough in practical use? I dunno... Ideas wanted... I had some ideas about this, and I'm sure it can be done with height-for-width in mind, however the y baseline(s) need to be calculated on a per width basis (i.e. as you're problem statement indicates, one y baseline can not rule-them-all as the required y anchor point might differ depending on the width, so probably the size requesting cache needs to also cache any baselines reported). Yes, baselines are per-width and needs caching. I don't think something particularly iterative is needed for this either, just need to virtually allocate the children in the request phase. I don't understand how that helps at all with the size allocate phase. See the example I gave in my mail to mathias. Also, I'm not convinced that 'baseline' is the right word for this API, I would rather consider it in terms of X and Y anchor points (if we handle this complexity in one orientation, we should be able to get the other orientation with relatively little added effort). On the contrary, baseline is *obviously* the right thing. Its what 99.999% of all uses of this will be, its what people will naturally look for in the API, and its what other APIs use. I also don't think it necessarily makes a lot of sense to allow vertical baselines. Vertical text is extremely uncommon and i can't think of any real life usecases for this. The size machinery is already slow enough that I don't think its worth adding theoretically useful functionality making it even slower. Another thing, is that we need the ability to calculate more than a single anchor point in a given orientation per widget. The one 'baseline' per widget wont pan out in the long run. I disagree. Sure, there will naturally be several *possible* baseline in a given child when you're aligning a container. However, only one will *actually* ever be used, so as long as you can select the proper baseline on the child widget itself there is no need for the general layout machinery to know about this. For instance, multi-line labels obviously have several potential baselines. But that is solvable by a call like gtk_label_set_use_baseline (label, GTK_LABEL_BASELINE_LAST); Similarly with a vbox like container you would get a potential baseline per child widget, but as long as you can tell the vbox which child it should inherit the baseline from you know what the baseline of the vbox is. There are cases where there are muliple baselines in a single container. Like a GtkGrid or GtkTable, where each row has its own baseline. But that is completely inside the size machinery of the grid implementation itself. Seen from the *outside*, like when putting the grid itself into a hbox and baseline aligning it would only have *one* baseline. +--+ | Horizontal Box (or Grid) | | | |+---+ | | +-+| Vertical Box (or Grid)| | | | Image || ++ | | | | || | Label | | | | +-+|~~~++ | | || | | || +---+ | | || | Other Content | | | || +---+ |
Re: Answers to some comments about frame synchronization
On fre, 2013-02-15 at 22:48 -0500, Owen Taylor wrote: On Fri, 2013-02-15 at 09:21 +0100, Alexander Larsson wrote: In terms of using timeBeginPeriod() and timeEndPeriod(), unfortunately, the GDK level API has no concept of a running animation, so it's not clear when GDK would set up a period. We could add such a thing - basically gdk_frame_clock_begin_continual_updates() - which would help for style animations and gtk_widget_add_tick_count(). It wouldn't help if a higher level built on top of GTK+ has an interface like window.requestAnimationFrame() or we're reacting to mouse events. We could add such an api though. For instance, we could have a refcounted api on the paint clock like gdk_paint_clock_use/unuse() such that any running animations would cause a clock use and thus higher timing resolution on win32. I tried creating such an API - patch at: https://bugzilla.gnome.org/show_bug.cgi?id=693934 It's a reasonable addition, and in some ways an improvement, though it makes the API a bit less minimal. This seems reasonable to me. I added some win32 support patches and timeBeginPeriod support to the bug. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Answers to some comments about frame synchronization
On fre, 2013-02-15 at 09:21 +0100, Alexander Larsson wrote: On tor, 2013-02-14 at 16:18 -0500, Owen Taylor wrote: On Thu, 2013-02-14 at 15:35 -0500, Alexander Larsson wrote: I did a bunch of research on this, see the g_get_monitonic_time() win32 implementation for it. I definately don't think we can just rely on QPC as is. Its not monotonic, it will drift over time and i believe over e.g. cpu sleeps. If we use it we should slave it to the lower precision clock in some kind of PLL (this is what firefox does). I just couldn't be bothered with the complexity last time... The Firefox bug linked to from the GLib comments is 5 years old, and in following through to various links, all the problems people were describing were with Windows XP. I'm not convinced that this is a current problem. DwmGetCompositionTimingInfo() which is the primary interface we might want to interact with uses QPC time, so my impression is that Microsoft's view of QPC is that it gives you sane timestamps along the lines of CLOCK_MONOTONIC on Linux, and not uninterpreted rdtsc values. That might be true, although we still support XP. All the official MS docs on this are really unclear though, which is kinda strange. http://msdn.microsoft.com/en-us/windows/hardware/gg463266.aspx seems to have some details though. It talks a bout timer coalescing too, which we should perhaps make the g_timeout_add_seconds calls use. Here are some other references: http://www.belshe.com/2010/06/04/chrome-cranking-up-the-clock/ http://gamedev.stackexchange.com/questions/32183/high-resolution-timer-options-in-windows http://stackoverflow.com/questions/5559985/handling-the-game-loop-with-os-timers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Answers to some comments about frame synchronization
Some more feedback: Cut and paste doc bug: * @GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS: corresponds to GdkFrameClock::flush-events. Should not be handled by applications. * @GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT: corresponds to GdkFrameClock::flush-events. Should not be handled by applications. The last one should be before-paint Did you try this on win32? The default timer resolution there is ~16msec which is about the 60Hz frame rate, which seems like it can cause some framerate instability. Its possible to temporarily raise this resolution by calling timeBeginPeriod() although its frowned upon to always do this as it raises total system cpu use. Maybe we could hook this up to the default paint clock, so that whenever we're doing regular animations we increase the timer resolution. I see that GtkTickCallback got a bool return value similar to GSource, which is bound to have the same kind of confusion wrt what value does what. Maybe we should have the G_SOURCE_REMOVE/CONTINUE equivalents already from the start to avoid this confusion. I think the motion compression is still mishandling motion events from different devices, so that if you get two motion event streams for the same window from two devices they will be compressed together. Also, there seems to be no compression of touch events, which seems kinda wrong, does it not? But in general i think we should land this ASAP and work it out from there. The new APIs look good to me and we desperately need this as we're starting to play more with animations in Gtk+ in general. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Answers to some comments about frame synchronization
Did you try this on win32? The default timer resolution there is ~16msec which is about the 60Hz frame rate, which seems like it can cause some framerate instability. Its possible to temporarily raise this resolution by calling timeBeginPeriod() although its frowned upon to always do this as it raises total system cpu use. Maybe we could hook this up to the default paint clock, so that whenever we're doing regular animations we increase the timer resolution. I haven't tested on anything but X11. My feeling is that we should just switch g_get_monotonic_time() to using QueryPerformanceCounter() on windows, and not worry about all the warnings you find on the internet that on some old version of windows on some buggy bios that QPC jumps as you switch between cores. If it turns out that doesn't work, we can write some function that combines GetTickCount() and QPC and sanity-checks, interpolates, etc, but we really shouldn't do so without having demonstrated existence of such buggy systems among our user base. I did a bunch of research on this, see the g_get_monitonic_time() win32 implementation for it. I definately don't think we can just rely on QPC as is. Its not monotonic, it will drift over time and i believe over e.g. cpu sleeps. If we use it we should slave it to the lower precision clock in some kind of PLL (this is what firefox does). I just couldn't be bothered with the complexity last time... And anyway, the QPC time is just for reporting time. A poll() sleep (i.e. MsgWaitForMultipleObjectsEx) will still use the timeGetTime precision, so it does not help here. after 15 years it doesn't seem confusing to me! We could just document that people should spend 15 years first! The two possibilities here would be: * Document people to use G_SOURCE_REMOVE / G_SOURCE_CONTINUE - this is the maximally consistent approach. I'd say go with this. I think the motion compression is still mishandling motion events from different devices, so that if you get two motion event streams for the same window from two devices they will be compressed together. Ah, yeah, forgot about that. Do you think it needs anything more complex than the attached patch. I don't think getting continual streams of events for two devices is going to be common, so I'm not sure it's worth worrying about compressing interleaved streams. Nah, that seems fine. Also, there seems to be no compression of touch events, which seems kinda wrong, does it not? I think that should certainly wait until we have real usage of touch events to figure out. Emmanuele probably makes a good point that full history is probably more commonly useful for touch than it is for mouse motion where only painting programs actually care. Yeah, lets skip this for now. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: touch on HTML5 supported by gtk+?
On tis, 2013-01-08 at 12:21 -0800, Andy Tai wrote: Hi, with gtk+ 3, is touch input supported with the HTML 5 backend, such as when running a gtk+ app on HTML 5 in the browser? Not currently, but it could be implemented. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sharing CSS code between Gtk and the Shell
On ons, 2012-12-12 at 19:01 +0100, Giovanni Campagna wrote: The second option is to share just code, in some form, either as a private shared library that would be provided by Gtk (libgtk-internal?) and developed by both teams, or just as a copy-lib, with a massive s/Gtk/St/. I'm not sure what would be the cost of this last possibility, but I'm still convinced it would be lower than rewriting from scratch, and maintaining two different CSS implementations in GNOME. I think this seems like the more doable approach. The gtk css machinery is very much not a public API/ABI and it changes a lot internally and needs to continue doing so. However, just splitting out the code doesn't really work well as it will conflict with symbol names and GType names if both are pulled into the same binary. So, we would need some kind of setup where cpp defines modify the exact prefix on symbols and GType names. That way we can use two different out-of-sync versions of the code in the same process. Of course, just splitting this out will be quite some work, as there are a number of interdependencies with the gtk+ code... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Broadway status
On mån, 2012-12-03 at 10:06 +0100, Jean Parpaillon wrote: Hi all, I've been trying gtk broadway backend and found it very interesting, even if it still lack some features to be completly usable in the real life :) Is there a roadmap for it ? Was it just a proof-of-concept, or is there something planned to make it a real web application framework, with offline operations, high-level html (like boxes, text, and such...) ? It was more of a proof of concept. I don't really have any time to do major work on it, nor do i have any particular planned usecases. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Solved] Re: [gobject-introspection] callback without GDestroyNotify
On ons, 2012-10-24 at 11:34 +0530, Mohan R wrote: On Tue, 2012-10-23 at 19:43 +0100, Emmanuele Bassi wrote: hi; don't use the G namespace for you code unless you plan on submitting it for inclusion in GLib. If you're writing a gtweet library, then the namespace ought to be Gtweet. ciao, Emmanuele. Of course I'm going to submit to gnome. But I'm trying to get it introspection ready and create a small application before submitting. Without introspection writing a webapi library is useless. Writing a library is one thing, but using a prefix like g_ in g_tweet_object_samplestream implies that this is part of glib. You need to use a different prefix, like gtweet_ or you risk conflicts with later symbols added to glib. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Frame synchronization open questions
On tor, 2012-10-04 at 15:46 -0400, Owen Taylor wrote: On Thu, 2012-10-04 at 08:09 -0400, Alexander Larsson wrote: Are you sure that is really a problem? The x11 gdk_event_source_check() code will never even look for a message if there is any GdkEvent queued. And if there is nothing queued _gdk_x11_display_queue_events() will stop as soon any X event was converted to a queued GdkEvent. And, since this queued event will not be read due to the pause we will never process more X events until resume events. That gets into the details of exactly how I implemented event pausing, but logically speaking, if event delivery is paused, and a new event happens, it needs to be queued up in GDK, Xlib, or in the X server. If we don't translate events, then either: If we start to translate and queue multiple X events into the gdk queue there is a lot more risk of the translation getting things out of order, so i don't think that is quite safe. So, yeah, queuing in xlib seems better. * Event is queued in Xlib, XPending() starts returning TRUE * Event is queued in XServer, the file descriptor Either situation is going to make us start spinning currently. But leaving that aside, we *need* to translate events or we'll never get _NET_WM_FRAME_DONE and unfreeze event delivery. We could find it via XCheckIfEvent, although that risks not being able to find it if the server side fd is full when its written and we never read from the X fd. Not sure if that can happen. My current preference is to just unfreeze all event delivery at the end of drawing the frame, and not wait for _NET_WM_FRAME_DONE. Then we can make pausing *really* pausing - not unqueue, not translate, etc. I don't see any real disadvantage of doing things that way. I agree. This seems clearly safest. Another thing I worry about is offscreen window animation. If you have an window with an embedded offscreen inside, then queueing a redraw on a widget inside the offscreen will cause a repaint cycle. When drawing to the offscreen this will generate damage events that will cause the embedding widget to repaint itself. However the damage events will be emitted during the paint phase, and the parent widget will not get these until the next frame. This will cause a delay of on frame which may look weird. Hmm. So your concern is that the connection between the embedded offscreen and the embedder is purely at the GTK+ level - if GDK_DAMAGE events are not delivered to GTK+, then the the embedder won't know to repaint. Actually, it depends a bit on how the event freezing works. Damage events for offscreens are emulated (to make it work even without damage X support and on other platforms) it the sense that gdk_window_process_updates_recurse does: if (gdk_window_is_offscreen (window-impl_window) gdk_window_has_impl (window)) _gdk_window_add_damage ((GdkWindow *) window-impl_window, expose_region); Which will queue a gdk side event (i.e. X and X event translation is not involved). So, if we freeze at the gdk level we will not get these during the paint cycle, but if we do it at the X level we might. So the offscreen will generally paint during the wait for _NET_WM_FRAME_DONE, and immediately get incorporated into the next output frame. Though once things get loaded down and slow, there is no guarantee of this. Yes, there will always be a delay of one frame for the embedded side vs the embedder side. To do better than this, I think you need to slave the clock for the offscreen into the clock for the window that is embedding it. If the size of the embedded widget is free-floating and not constrained by the allocation of the embedder, then the slave clock would simply do the complete cycle inside an ::update handler. If you want integration of size-negotiation, then you'd have to do different phases at different points in the master clock cycle. Maybe the widget could manually ensure the offscreen widget gets the same clock at construction time. But thats not really enough is it? You have to guarantee that the embedded widget draws before the embedder. And yes, the delivery of damage as events is problematical for that kind of slaving - maybe we would need to have a signal on GdkOffscreenWindow to allow getting as-it-happens notification of damage. Yeah. Also, for something completely different. With the frame based motion compression we should imho completely remove the motion hints support. There is a bunch of code in the csw stuff to emulate it which becomes pretty much useless with this. And we never pass on motion hint masks to the xserver anyway since we only get events on the toplevel and motion hints are generally enabled on some subwindow. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Frame synchronization open questions
Some open questions in my head about the frame synchronization work: * Is GdkPaintClock the right name? It might imply that it only has to do about painting and not about other things like layout. GdkFrameClock would be an alternative. GdkClock is possible but likely too generic. I agree that Paint is confusing, GdkFrameClock seems to be the right name to me. Frame is what this is always called in gameloop style code. * For pausing the main event delivery, what we currently do is that we queue events but don't dispatch them. This could conceivably cause ordering problems for apps that use filters, or for work in GDK that is done at the translate stage - since we are not pausing translation, just pausing delivery. Alternatives: Are you sure that is really a problem? The x11 gdk_event_source_check() code will never even look for a message if there is any GdkEvent queued. And if there is nothing queued _gdk_x11_display_queue_events() will stop as soon any X event was converted to a queued GdkEvent. And, since this queued event will not be read due to the pause we will never process more X events until resume events. So, we may process multiple events that are not queued into gdk events and at most one that is queued, but no more until the queued event is handled. This does not look like it could ever cause a reordering problem to me. At most it means we may handle some filtered X events during the frame cycle, I'm not sure that is as much of a problem. What I do however worry about is the combination of multiple GdkPaintClocks and gdk_display_set_events_paused(). It seems to me that each paint clock assumes it has full ownership of the display, calling set_events_paused(FALSE) whenever it has finished its paint cycle. However, could there not be other paintclocks (say for another toplevel) being active at that time? Another thing I worry about is offscreen window animation. If you have an window with an embedded offscreen inside, then queueing a redraw on a widget inside the offscreen will cause a repaint cycle. When drawing to the offscreen this will generate damage events that will cause the embedding widget to repaint itself. However the damage events will be emitted during the paint phase, and the parent widget will not get these until the next frame. This will cause a delay of on frame which may look weird. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Partial frame synchronization TODO
? Implement paint throttling for the Broadway backend. (I'm not sure what this means exactly - the default throttling to 60fps may be OK.) Not sure what the best thing is here. If you have a low bandwidth connection then you would like to do a roundtrip to the client before sending the next frame to avoid just filling up the pipe with frames and then blocking on socket write. However, if you have a high bandwidth but high latency link then you could theoretically keep sending new frames and they would display fine on the client, although somewhat delayed. Doing the roundtrip in this case would just unnecessary skip frames in the animation. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: reversible
Not a lot of serious feedback here, but I also worry about the implicitness about this API. Its really not well defined what it does, and the fact that it may change over time as functions are implemented differently or new things support reversible just seems scary. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk_pixbuf_new_from_file_at_scale() returning error saying Unrecognized image file format when loading png files
On Tue, 2012-06-12 at 14:40 +, avijit.ma...@wipro.com wrote: Hi, On further debugging I could see the below behaviour: 1. _gdk_pixbuf_get_module receives the buffer header as:89PNG 2. But when it fetch the mime_type on that buffer it is getting mime_type:application/octet-stream which should be image/png. Due to this there is a type mismatch in mime_type and hence it is returning error with Unrecognized image file format. Any idea which could be the reason for this mime_type mismatch? Gdk-pixbuf optionally uses gio to do mime sniffing, which requires the shared-mime-info package to be installed. However, the configure script for gdk-pixbuf explicitly tries to sniff the mimetype for some png data, and only enables this if that worked. Are you are building and deploying gdk-pixbuf in different contexts? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk_pixbuf_new_from_file_at_scale() returning error saying Unrecognized image file format when loading png files
On Wed, 2012-06-13 at 10:16 +, avijit.ma...@wipro.com wrote: Do I need to export any variable also? XDG_DATA_DIRS=$WLD/share:/usr/share You probably also want XDG_CONFIG_DIRS, and obviously things like LD_LIBRARY_PATH and PATH. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ropes and String Formatting
On Thu, 2012-05-24 at 22:21 -0400, Colin Walters wrote: On Mon, 2012-05-21 at 06:54 -0400, Russell Harmon wrote: I'm looking to implement two things which I think would be quite useful if included in glib. - Ropes [1] The basic rule is - something might go in GLib if used by 2 (preferably 3-4 or more) components. Yes, glib is not a general set of abstract data types, it just has a few very often used ones. We don't add new ADTs just because they look like they could be useful for something. So, unless you have say Gtk+, glib internals or multiple apps depending on some ADT its unlikely to go into glib. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
- Original Message - On Tue, 03 Apr 2012 23:35:46 -0400 Colin Walters walt...@verbum.org wrote: On Wed, 2011-11-16 at 21:05 +0100, Mikkel Kamstrup Erlandsen wrote: Hi all, I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. So this is frankly pretty cool - but we can't make GLib/GTK+ dependent on GNU C. I guess that for glib these things are matters of degree rather than principle. glib now uses gcc's constructor and destructor attributes since, I think, version 2.32 (I believe that is when gconstructor.h first appeared), presumably on the grounds that, although non-standard, they are also found in most mainstream compilers likely to be used with glib. What it uses is constructors, not particularly the gcc ones (although they are used with gcc). On MSVC and SunCC we use the native compiler methods to create constructors and destructors. Constructors are a required feature of C++ and all OSes that want to support C++ have to somehow handle them, and its also pretty common for C code to use them. So, I don't think its comparable at all to something that is specific to gcc only. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
gcc's constructor and destructor attributes as I understand them are principally used in connection with the loading and unloading of shared libraries at program start-up and close down, although I imagine they have other uses. If you say those may require OS support I will believe you (certainly shared libraries do), and in terms of ubiquity I do not dispute that their use and/or availability for C is more widespread than, say, cleanup attributes. I might have been a bit sloppy with my words, but the following C++ code, in a shared library: MyClass my_object; Needs to have the MyClass constructor for the static object my_object run before the main() function in your application. This is identical to attribute constructor (in fact, implementation wise thats how this works in C++). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeekable and GBuffered{In,Out}putStream, GDataOutputStream
On Wed, 2012-03-28 at 14:32 +0200, Maciej Marcin Piechotka wrote: Hello, During discussion on bug #659781[1] a user stated that he cannot use GDataInputStream as it does not support seeks. After quick look it seems that adding support for it is relatively easy - the basic patch for GBufferedInputStream is +117/-4[2]. I can fill a full bug, test etc. but I would like to check first if it wasn't a deliberate choice. There is no conceptual reason for it to no support seek (although it has to handle the case where the base stream can't seek), only laziness. So please do file a full bug! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Signal emission changes
I just landed a bunch of signal emission optimizations in gobject. It should be transparent to everyone, although it you're using an non-standard signal marshaller for a heavily used signal you might want to look at setting a custom va_marshaller. The basic idea is that for a the (common) case of a single signal handler when various complex signal emission features are not in use we can avoid collecting the va_list from g_signal_emit_valist() into GValues and demarshall the va_list immediately into the callback arguments. This gives performance increases in the range 10-20 fps in the clutter performance checks, and could also help in e.g. the gtk+ size allocation machinery. I've added some new signal tests, and I'm running my entire session with this without any problems. However, its possible that there is some edge case that broke, so if you see weird behaviour wrt signal emissions try a glib without this change and report any problems to me. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+-2.24.8 became the current maintained version on win32 ??
On Thu, 2012-01-19 at 11:47 +0800, jun louis wrote: I found this BUG: I directly run gtk-demo.exe on win7 x64, use locale=zh_CN, texts disappear when switch page. I use msys, use LC_ALL=C then run gtk-demo, texts works fine! $ export LC_ALL=C $ ./gtk-demo.exe I use msys, use LC_ALL=zh_CN then run gtk-demo, texts disappear~~~ $ export LC_ALL=C $ ./gtk-demo.exe This is just a guess, but perhaps this is font related? Maybe it doesn't find the chinese fonts? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Wed, 2012-01-18 at 11:56 -0800, Christian Hergert wrote: 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. Thats not really possible. The way this works is that it sets an X property that the compositor uses when painting the window pixbuf. The compositor doesn't know what areas are part of some subwindow or subwidget. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: 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. There is some level of validation in the gtk+ printing dialog. The printer configuration files (PPD files) can specify certain combination of enabled features as incompatible (i.e. can't do full duplex while stapling or whatnot). Whenever something is invalid we show a label somewhere explaining the problem and then each problematic settings widget gets a warning icon. This is imho a pretty nice way to handle validation. You're not unable to input invalid input (which can be confusing), but you get instant feedback on when and what is invalid. 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 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. Not only does it help with animation, but its also nice in terms of size allocation. Often you want a set of widgets that can temporarily change into another set (for instance during editing) without causing a UI reflow. Having a widget stack like this helps with this size allocation handling. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Wed, 2011-12-21 at 15:07 -0800, Hub Figuière wrote: On 21/12/11 02:47 PM, Alexander Larsson wrote: I think this could be very useful in many places, for instance to ship built-in css files, gtk builder files, win32 theme images etc in a way that still makes libraries relocatable (and avoids potential for runtime errors due to not found files). Maybe we could actually support bundles like it is done on MacOS. The idea of compiling data into a binary file give me a blast from the past from the MacOS 9 days. See: http://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Wed, 2011-12-21 at 17:47 -0500, Alexander Larsson wrote: I just finished a one-day hackathon to add a resource framework to glib, its somewhat working if not very polished. Its in the resources branch in glib git. I think this could be very useful in many places, for instance to ship built-in css files, gtk builder files, win32 theme images etc in a way that still makes libraries relocatable (and avoids potential for runtime errors due to not found files). Feedback on the concept and the code welcome... Time to leep... Ok, I pushed a few changes to the API and a few new features/fixes: * On linux the resources end up in separate named readonly data sections: readelf -S gio/tests/.libs/resources ... [16] .gresource.test2 PROGBITS 00402d38 2d38 00ac A 0 0 8 ... This means you can extrace resources from existing binaries. * GBytes is used in the APIs where useful * Support for optionally compressed resources Note: You can only stream these, not get at the underlying bytes * Support for locale specific resource alternative You can replace individual resources based on the current locale * Guarantee zero termination of the raw data you get when looking up data I think this is in a better state than yesterday. The outstanding issues i see are: * Documentation * Test the constructor macros on more compilers/OSes * We should modify gvdb so that it groups all the key strings used for the hash lookups consecutively, instead of mixed with the data. This would mean touching less pages during lookup. * Figure out how to handle unloading This last one is the hardest one. Right now i'm using g_atexit() from the constructor. This means that on at least win32 and glibc = 2.2 we'll get called when the module is unloaded, but on other arches we might not be called until the process terminates. Both of these create issues. If its called on exit we will crash on exit due to the call into nonexisting code. But we will also be keeping registered global resources that point into data that doesn't exist anymore. If we get called on module unload things a much better, we will generally not crash, and we will properly unregister the resources for the module. However, any outstanding data (GBytes or GInputStreams) from the resource will suddenly see their backing go away. We could possibly keep track of these and neuter the objects, but if you have e.g. a raw pointer to the data then there is no way to get notified of this. I'm not sure what the best approach is here. The later problem seems avoidable by not keeping data around for too long, but the problems with atexit being broken is hard to work around. Is there some other alternative though? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Glib resource framework
I just finished a one-day hackathon to add a resource framework to glib, its somewhat working if not very polished. Its in the resources branch in glib git. I think this could be very useful in many places, for instance to ship built-in css files, gtk builder files, win32 theme images etc in a way that still makes libraries relocatable (and avoids potential for runtime errors due to not found files). Feedback on the concept and the code welcome... Time to leep... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On Fri, 2011-12-09 at 08:47 -0500, Ryan Lortie wrote: On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote: Windows actually has an application menu thing. If you right-click on the application on the panel you can get app-specific operations in the menu. I'm not sure if the normal usecase for these match what the app menu is typically used for though. Is this the so-called jumplist? It sounds more likely that we'd treat this as a 3rd type of menu -- since the shell, unity and mac os all have this same concept these days as well... Yeah, this is one instance of the jumplist. The other one being on the app icon in the start menu. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO performance improvements
On Tue, 2011-11-15 at 17:49 +0100, André Gillibert wrote: I'm not sure this mailing list is the correct place to post GLIB-related requests, but I didn't find a glib-devel-list. I wrote a patch for GLIB 2.28 GIO subsystem to benefit from dirent::d_type and be as lazy as possible on lstat(2)/stat(2)/readlink(2)/access(2) syscalls on local file system when information is requested on a GFile or when a directory is listed. This patch is not yet very clean or commented but I can improve it before submitting it. May this type of patch be accepted in GIO ? Actually, I wrote this patch to bring dramatical performance improvements to Thunar-1.2, but I may wrote similar patches for Nautilus. Benjamins patches for this is already in git master. However, it is unlikely to help in many cases, only when you're *only* interested in name and file type (not including e.g. mime type (and thus icon)) is this useful. One particular place it *is* useful though is typeahead completion which is what benjamin needs it for, and i guess we should do that in nautilus too. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.24.8
GTK+ 2.24.8 is now available for download at: http://download.gnome.org/sources/gtk+/2.24/ ftp://ftp.gnome.org/pub/GNOME/sources/gtk+/2.24/ ac2325a65312922a6722a7c02a389f3f4072d79e13131485cc7b7226e2537043 gtk+-2.24.8.tar.bz2 8a3b29f667933cf52eea2db7b066723edbc80443ca9c75b7cd7cbe8c8b90b93c gtk+-2.24.8.tar.xz This is a bug fix release in the stable 2.24 series. GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Overview of Changes from GTK+ 2.24.7 to 2.24.8 == * Win32 updates: Major update of the win32 backend, it now works at least as well as the old 2.16.x version that a lot of windows applications was forced to use Some particular highlights: - Tablet support (wintab) works - The MS-Windows theme works better, and is enabled by default on Windows - Pointer grabs on button press now works - Initial Window positioning is improved and now works very similarly to the X11 backend - Scrolling a window with another window overlapping it doesn't produce rendering artifacts on XP - Configure event delivery after window move or resize is much more robust, fixing a variety of rendering hangs and misbehaviours - Scrolling with synaptics touchpads work better * OS X updates: - Add Command-cursor keyboard navigation in text widgets - Fix loss of motion events after using the menu bar - Handle recursive CFRunLoops, fixing e.g. crashes when dropping files from finder - Set proper event-state values in all events * Ensure that the MOD1 modifier always means ALT, as this assumption is already used in many places in Gtk+ * Search engine backend updated to Tracker 0.12 * Bugs fixed: 84314 gdk_display_sync() and gdk_flush() 142874 use of SetWindowLong in gdkwindow-win32.c causes... 169811 configure_event and window-state-event are not... 171456 Keep Above option in Gimp broken on Win32 324254 Realizing a top-level window widget early positions... 516822 gtk_window_fullscreen does not resize correctly if... 537296 Maximizing a window larger than the screen makes... 542777 Scroll-Wheel doesn't scroll (Win) 552041 Windows' System Menu from taskbar is buggy 574935 win32: gtk_window_set_geometry_hints() has no effect... 604156 gtk_window_set_modal() freezes application completely 612359 Dialog positioning hints fail on Windows 7 631384 Images pasted from clipboard are shifted/wrapped 647460 typo in msw_style.c? 650300 Notebook tabs are incorrectly displayed with the... 658272 Port gtksearchenginetracker.c to tracker 0.11/0.12 659565 unbreak compilation on OpenBSD 661997 Gtk crashes when changing the TreeView model while ... 662633 Scheduled transaction editor crashes with gtk+-2.24.7 662670 Pressing Enter in print dialog box will not cause... 663138 iconview: layout items immediately when setting... 663182 NSImage throws an exception from _gtk_quartz_... 663543 Huge memory leak while using MS-Windows theme (gtk-demo) 663605 Fix event-state of many event types on quartz November 10, 2011 Alexander Larsson ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ 2.24.8
GTK+ 2.24.8 is now available for download at: http://download.gnome.org/sources/gtk+/2.24/ ftp://ftp.gnome.org/pub/GNOME/sources/gtk+/2.24/ ac2325a65312922a6722a7c02a389f3f4072d79e13131485cc7b7226e2537043 gtk+-2.24.8.tar.bz2 8a3b29f667933cf52eea2db7b066723edbc80443ca9c75b7cd7cbe8c8b90b93c gtk+-2.24.8.tar.xz This is a bug fix release in the stable 2.24 series. GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Overview of Changes from GTK+ 2.24.7 to 2.24.8 == * Win32 updates: Major update of the win32 backend, it now works at least as well as the old 2.16.x version that a lot of windows applications was forced to use Some particular highlights: - Tablet support (wintab) works - The MS-Windows theme works better, and is enabled by default on Windows - Pointer grabs on button press now works - Initial Window positioning is improved and now works very similarly to the X11 backend - Scrolling a window with another window overlapping it doesn't produce rendering artifacts on XP - Configure event delivery after window move or resize is much more robust, fixing a variety of rendering hangs and misbehaviours - Scrolling with synaptics touchpads work better * OS X updates: - Add Command-cursor keyboard navigation in text widgets - Fix loss of motion events after using the menu bar - Handle recursive CFRunLoops, fixing e.g. crashes when dropping files from finder - Set proper event-state values in all events * Ensure that the MOD1 modifier always means ALT, as this assumption is already used in many places in Gtk+ * Search engine backend updated to Tracker 0.12 * Bugs fixed: 84314 gdk_display_sync() and gdk_flush() 142874 use of SetWindowLong in gdkwindow-win32.c causes... 169811 configure_event and window-state-event are not... 171456 Keep Above option in Gimp broken on Win32 324254 Realizing a top-level window widget early positions... 516822 gtk_window_fullscreen does not resize correctly if... 537296 Maximizing a window larger than the screen makes... 542777 Scroll-Wheel doesn't scroll (Win) 552041 Windows' System Menu from taskbar is buggy 574935 win32: gtk_window_set_geometry_hints() has no effect... 604156 gtk_window_set_modal() freezes application completely 612359 Dialog positioning hints fail on Windows 7 631384 Images pasted from clipboard are shifted/wrapped 647460 typo in msw_style.c? 650300 Notebook tabs are incorrectly displayed with the... 658272 Port gtksearchenginetracker.c to tracker 0.11/0.12 659565 unbreak compilation on OpenBSD 661997 Gtk crashes when changing the TreeView model while ... 662633 Scheduled transaction editor crashes with gtk+-2.24.7 662670 Pressing Enter in print dialog box will not cause... 663138 iconview: layout items immediately when setting... 663182 NSImage throws an exception from _gtk_quartz_... 663543 Huge memory leak while using MS-Windows theme (gtk-demo) 663605 Fix event-state of many event types on quartz November 10, 2011 Alexander Larsson ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: gtk-2-24-win32 branch update
On Sat, 2011-11-05 at 00:06 +0800, Fan Chun-wei wrote: So, could everyone interested in the windows support test this please. I'd like to make a 2.24 release with this stuff in it so that we have a final Gtk2 with good win32 support. Obviously we don't want to have any bad regressions for existing Gtk win32 apps in this release, so *please* test stuff. I think things basically went alright with the Visual C++ builds-but I have not yet integrated the ms-windows theme portion into the project files, which I would most likely build it right into the main GTK+ DLL if that is desired. Please let me know if integrating the ms-windows theme bits is the ideal way here, so I could update the items here. Compiling the windows theme into the main dll sounds fine, as long as it still works without it. I.e. if you select another theme that doesn't use that theme engine things should still work. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-2-24-win32 branch merged into gtk-2-24
The -win32 branch is now in a pretty good state and seems to be the best Gtk 2.x version for win32 so far, so I just merged it into gtk-2-24, and I plan to do a release later this week. The latest code also includes a bunch of Quartz fixes, so this will end up being a pretty sweet cross platform release. So, this is a last call for any regressions vs earlier win32 releases before doing the new release. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-2-24-win32 branch update
On Fri, 2011-11-04 at 16:38 +0100, Maarten Bosmans wrote: So, could everyone interested in the windows support test this please. I'd like to make a 2.24 release with this stuff in it so that we have a final Gtk2 with good win32 support. Obviously we don't want to have any bad regressions for existing Gtk win32 apps in this release, so *please* test stuff. I tested it by building it on the OBS and compiling my app against the new packages. Testing went well under Windows XP and 7. Several things I noticed before have improved now. Thank you very much for your efforts! The only regression I could spot was caused by defaulting to the ms-windows theme. It only popped up because my app uses a murrine-based theme. The solution was to override some settings from ms-windows gtkrc to the murrine gtkrc. Even though for me it was a regression, I don't think that commit has to be changed, as almost nobody uses the murrine theme engine on windows. Yeah, i think most people will want the MS-Windows theme. You can still change it by editing your ~/.gtkrc-2.0 file as before, only the default changed. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-2-24-win32 branch update
The gtk-2-24-win32 branch is now in a pretty good state. I fixed a lot of bugs from bugzilla and stuff from dieters testing (https://live.gnome.org/GTK%2B/Win32/test-gtk-2-24-win32). I think this is in a state where we might want to merge it into master. I fixed most core issues, although I didn't fix the MS-Windows misrendering bugs that dieter pointed out. So, could everyone interested in the windows support test this please. I'd like to make a 2.24 release with this stuff in it so that we have a final Gtk2 with good win32 support. Obviously we don't want to have any bad regressions for existing Gtk win32 apps in this release, so *please* test stuff. My plan going forward is to mostly leave this code as-is (i.e. mostly working but no new features) and move towards fixing Gtk 3.x on win32. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On Fri, 2011-10-21 at 10:36 +0200, Kean Johnston wrote: Can any people interested in the win32 code please try this out and report any issues, regressions against gtk-2-24 or just things that are broken on windows related to windows and events. I just updated jUXtapose to your code and things look OK to me. I'm not 100% sure exactly what your changes affect so if you can give me something specific to try and test I am happy to do it. Its mainly about how enter and leave events are being sent, and how grabs work (both explicit and and implicit grabs from pressing a button). Things to test are: everything related to menu behaviour (rich in grabs), everything involving press-and-hold-down mouse button behaviour, checking that the right things prelight as you move between windows and widgets. However, this is also more of a call for feedback about places where the current Gtk 2.24 code fails for you on windows. I'd like to know so i can try fixing it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On Fri, 2011-10-21 at 10:49 +0200, Arnaud Charlet wrote: Things to test are: everything related to menu behaviour (rich in grabs), everything involving press-and-hold-down mouse button behaviour, checking that the right things prelight as you move between windows and widgets. However, this is also more of a call for feedback about places where the current Gtk 2.24 code fails for you on windows. I'd like to know so i can try fixing it. See https://bugzilla.gnome.org/show_bug.cgi?id=646930 for an example of a regression in 2.24 wrt grabs. I replied to this bug, it should be fixed already on the branch. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On Fri, 2011-10-21 at 11:53 +0200, Arnaud Charlet wrote: See https://bugzilla.gnome.org/show_bug.cgi?id=646930 for an example of a regression in 2.24 wrt grabs. I replied to this bug, it should be fixed already on the branch. Great, thanks for having a look! BTW, what's your estimate on looking at Gtk+ 3.x? Since 3.2 is now out, it would be great to have a stable 3.2 Gtk+ under Windows. Do you know about the status of 3.2 under Windows these days? I want to make sure 2.24 works well first, then I will look at porting the fixes to master (and then back to 3.2 branch which should be trivial). The forward port should be mostly mechanic and not a lot of work, as there has not been a lot of conceptual changes to the gdk code. The one problematic thing for 3.x is the windows theme. That requires a completely different approach (to integrate with the css) which will require some new work. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On Thu, 2011-10-20 at 01:49 +0200, Dieter Verfaillie wrote: On Wed, 19 Oct 2011 22:53:49 +0200, Alexander Larsson wrote: I just pushed a bunch of changes to how grabs and crossing events work in the win32 backend to the gtk-2-24-win32 branch, and I want to fix any other leftover bugs from the client side windows conversion. From my first tests (on Windows XP), this looks good. Even better, it's amazing to see some long standing bugs finally squashed. Thank you! I've not really used Gtk+ on windows for real, so I was mainly working from first principles in the code fixing stuff that was obviously wrong. Do you know of any other outstanding win32 bugs that I can look at? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On Thu, 2011-10-20 at 08:37 +, Andy Spencer wrote: First off, when using the MS-Windows theme, some widgets don't render correctly and show up as black boxes. For example, notebooks with tab position set to GTK_POS_LEFT don't render. This is possibly something else, but i'll have a look. Second, the GtkGLExt plugin has been broken since 2.18 I believe, the OpenGL area doesn't get set correctly because the widget you set it on doesn't have a native window (if I remember correctly). I've since given up on GtkGLExt and wrote my own x11 and win32 OpenGL interfaces, so I'm not sure if it's still an issue or not. Peter Clifton did some work on this, and with this commit: http://git.gnome.org/browse/gtk +/commit/?h=gtk-2-24id=fd01442c7e95a490607482a91987a3b72608a372 I believe GtkGLExt should nominally work (as in there might be minor issues with it but it shouldn't be completely broken). Please test it if you can. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
On Thu, 2011-10-20 at 18:15 +0200, Kristian Rietveld wrote: On Oct 20, 2011, at 12:03 PM, Clemens Eisserer wrote: I hacked together a simple sample application which compiles under gtk2 as well as gtk3: http://93.83.133.214/gtklist.c Just maximize it (preferable on a large screen) and scroll with your wheel - the gtk3 version should feel a lot slower. I have noticed that as well on GTK+ 3 a year ago or so, and I don't think this is specific to GtkTreeView. Back then I got the impression that some parts of the drawing synchronization (i.e. draw the moved area and the newly exposed area at the same time instead of first drawing the moved area and drawing the newly exposed area later) did not make it into the client-side-windows code. However, I was told that such problem should not exist with client side windows (I was not convinced though). The csw code takes a lot of care to try to ensure this. However, the csw code exists on Gtk+ 2.x too, so its easy to verify by comparing Gtk3 and a csw version of Gtk2. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gtk+ win32 fixes, please test
I just pushed a bunch of changes to how grabs and crossing events work in the win32 backend to the gtk-2-24-win32 branch, and I want to fix any other leftover bugs from the client side windows conversion. Can any people interested in the win32 code please try this out and report any issues, regressions against gtk-2-24 or just things that are broken on windows related to windows and events. I'm doing this work on the 2.24 branch because gtk2 is what most apps are still using on win32. When this seems to work well I want to forward port it to 3.2. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
On Mon, 2011-09-26 at 08:59 +0200, Kean Johnston wrote:
There is also a broader issue with stat. The size of struct stat can vary
according to what macros are defined when you include sys/stat.h. If you
have _FILE_OFFSET_BITS=64 defined your size fields are 64-bit, otherwise
they *can* be 64-bit but are most often 32-bit. Thus, if glib was compiled
without _FILE_OFFSET_BITS defined, and an application uses g_stat() but
DOES have it defined, you're in for trouble (and the inverse is true - if
glib was compiled with _FILE_OFFSET_BITS=64 and the app wasn't, the same
hilarity ensues).
I don't see how this would be any problem. Both the app and the library
will get the struct stat that matches what they were compiled with. The
only problem would be if you passed the struct stat between glib and the
app, but that doesn't happen as g_stat is a macro.
On almost all UNIX systems time_t is a signed 32-bit int thus capable of
representing time from the epoch through some time in 2038. Windows has
support for 64-bit time fields which is surprisingly forward thinking of them.
time_t is typically a signed long, which is 64bit on all 64bit linux
versions.
Since GLib is a platform library it would be extremely useful if
gstsdio.h defined a GLib version of the stat structures instead of just
doing typedef struct stat GStatBuf. That structure can be consistently
defined, with sufficiently large data types that it will work on all
systems. Despire the coolness of Windows supporting time fields 64-bits
wide for the least amount of pain it would probably be best if the time
fields were left at 32-bits (although it would be really cool and forward
thinking if we used 64-bits), but to use 64-bit fields for all size fields,
and 32-bit fields for all others. That way gstdio.[ch] can be compiled in a
very specific way to get the information needed and then smush it into that
portable structure. Here's how I would define the GStatBuf data type:
typedef struct GStatBuf {
guint32 st_dev;
guint64 st_ino;
guint16 st_mode;
guint16 st_nlink;
guint32 st_uid;
guint32 st_gid;
guint32 st_rdev;
gint64 st_size;
gint32 st_atime;
gint32 st_mtime;
gint32 st_ctime;
} GStatBuf;
I don't see what advantages this gives you. It will break all existing
code that uses g_stat and struct stat, you can't share GStatBuf with
other struct stat using code, you can't access extensions like
nanosecond mtimes, it doesn't have things like blocksize and st_blocks
which means you can't calculate actual space used.
Also, we *do* have an abstraction that lets you write portable code. Its
called GFileInfo. g_stat is by its nature a lowlevel unix-like call, it
was added mainly as a quick way to port unix code to windows. So,
introducing our own copy of struct stat on windows might make sense
(with its c runtime library issues), but we don't want to change it on
unix.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
On Wed, 2011-09-28 at 10:00 +0200, Kean Johnston wrote:
This means that there is an awful lot of valid existing code (including
within GLib itself) that looks like this:
{
struct stat buf;
g_stat (filename,buf);
}
which (if I understand your proposal correctly) would be badly broken.
That code would of course change to
{
GStatBuf buf;
g_stat (filename, buf);
}
It would be a break in source-compat, which we can't just do. Glib is an
API stable library used by thousands of other libraries and apps.
The code wouldn't be broken at all. In fact it would be less broken. If,
for example, GLib wasn't compiled with _FILE_OFFSET_BITS=64 then
internally, all of its usage of g_stat() can only deal with 31-bit file
sizes. User code using GLib compiled WITH that set will support file sizes
with 63 bits.
I don't understand why you keep bringing this up. glib has
AC_SYS_LARGEFILE in configure.ac, so it will never be built with
anything but 64bits internally.
Almost all of the functions currently wrapped in gstdio.h are problematic
with LFS. On Linux they are currently just macros.
They are problematic due to LFS being problematic, but that is just how
unix works. If you want to work with other libraries etc on the lower
level you have to be aware of this. If you don't want that, use the
proper glib i/o abstractions in GIO that are not using anything like
struct stat.
That supports the vast majority of the code out there that is UNIX-centric
and supports the notion of a 31-bit time field measured as seconds since
the epoch of Jan 1 1970. But code that wants higher precision can use the
64-bit variants on systems that provide it and simply multiply out the
32-bit ones to give usable values on those that don't.
All 64bit linux arches uses 64bit signed time_t, and its in seconds.
Higher precision timestamps are done in linux by introducing separate
nanosecond fields in struct stat. This is all transparently handled by
GIO if you just use GFileInfo.
Note that on Windows the 64-bit time fields are just more seconds since the
Epoch, with an upper limit of Dec 31 23:59:59 3000. If we decide that the
64-bit time field is really nanoseconds since the Epoch (a much more usable
value IMHO) then it can represent dates up to some time in the year 2262. I
don't think it matters what it represents as long as we define it. If GLib
only breaks in the year 2262 I'm quite Ok with that :-)
Of course we can't just make time_t be nanoseconds, that would break a
lot of other functions that expect it to be in seconds.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-2-30 hard code frozen
On Sun, 2011-09-18 at 10:50 -0400, Ryan Lortie wrote: hi everyone, I've been trying to follow the GNOME 3.1 release cycle fairly closely with GLib 2.29. For that reason, I now consider the glib-2-30 branch to be hard code frozen. Please do not commit anything without first asking for an exception. Oops. Sorry about that, i just commited a fix (http://git.gnome.org/browse/glib/commit/?h=glib-2-30id=7b812c434388f0fc3cbbb67df5ab9f7db3a138ed) before I saw this message... Consider this an exception request... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib next cycle update
On Sun, 2011-09-18 at 13:11 -0400, Ryan Lortie wrote:
- use a __attribute__((constructor)) approach
I have a patch here to introduce this concept as a quick hack:
http://git.gnome.org/browse/glib/commit/?h=wip/mutexesid=9f29daafeb8133611a4ea24f5013ebb8bb623d73
and two uses of it:
http://git.gnome.org/browse/glib/commit/?h=wip/mutexesid=7dd937f96b19f41d4eda4890dbbb57c6451cf4b6
http://git.gnome.org/browse/glib/commit/?h=wip/mutexesid=233e66c195ae828f75ecff3738124041d7b1e586
For the record, I think that this is a somewhat inelegant solution.
Maybe it's our best choice, though, given the constraints. I know
some others want to make use of this, and maybe we could even
consider making the API public (and cleaning it up).
I have doubts that we can ever support this everywhere in a portable
way but we can probably get pretty reasonable coverage. Matthias
also raised some concern about the undefined order in which the
constructors could be called (which means that we might have to
refrain from calling gslice from other constructors, for example,
since gslice may not have been initialised yet).
I want this anyway as a public API, as I want to add a resource
framework, and we need it to automatically add any resources in a
library to the global resource table when loaded. I have done some
research on how to do this on most reasonable architectures, and I think
it is reasonable to demand it for all glib targets.
Unfortunately the API for this is gonna be *horrible* due to the
different ways it is implemented. Lets look at them:
On GCC we can just use a __attribute__((constructor)) marker on a
function, so it can be a normal macro. This works on both linux and osx,
and all other elf-based unixes using gcc.
For non-gcc solaris (i.e. sun cc) we can use #pragma init:
http://download.oracle.com/docs/cd/E19205-01/819-5267/bkbki/index.html
Unfortunately this is a pragma, which doesn't expand macro arguments, or
is possible to put in a macro. The only way to do this as an API is with
#include, so you'd do
#include glib/glib-constructor-pre.h
G_DEFINE_CONSTRUCTOR (my_constructor);
#include glib/glib-constructor-post.h
Which does something like:
glib-constructor-pre.h:
#define G_DEFINE_CONSTRUCTOR(func) \
static void _glib_constructor (void) { \
(func) (); \
}
glib-constructor-post.h:
#pragma init(_glib_constructor)
Which, apart from looking ass, only works with one constructor per file.
For non-GCC windows (i.e. visual c) we can use this:
http://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc
This also uses pragmas, but doesn't have a fixed name at least, so the
one constructor per file doesn't apply.
As a last resort it is also possible to use the c++ compiler and create
a separate object file we can link into the app/library. This is harder
to use though, as it involves makefile trickery, etc.
A couple of solutions to that:
- use the (priority) field of GCC
- use internal rigging to ensure dependent inits are called first
or just use one big initialisation function that does it in the
right order
I think this is the right approach, its just plain more reliable and
debuggable.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib next cycle update
On Mon, 2011-09-19 at 09:54 -0400, Morten Welinder wrote: Unfortunately this is a pragma Will C99's _Pragma help? That can be put in a macro. It depends. Does all old crap compilers that forces us to use pragmas to mark constructor functions support it? My guess is no, but it might be worth researching. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
