Re: Modernizing the display loop [try 2]
it's possible something in here is useful: http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg4.html Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Hi, On Tue, May 31, 2011 at 5:47 AM, Christian Dywan wrote: > This is a great argument. There was a mistake. It made you notice the API is > inconsistent, so you suddenly insist that GLib can't be improved further > without rewriting all the functions It didn't "make me notice" - I've known about this issue for many years, including in all the other threads about it. I also wrote the GError API docs 11 years ago, which explain the issue. You can find years-old emails with me making the same "duplicate error-throwing API for bindings" point about libdbus, if you do some googling. This is a 15-year-old issue, or so. It's a tradeoff. We could redo thousands of functions with duplicate functions to be used only from language bindings, or we could live with this design decision. I personally think 15 years of experience show that we can survive without a major API redo. I agree that g_warning/critical can be nicer than g_error in a certain way, fwiw, though when it's up to me I make both abort and consider them the same. Anyway, I don't make the decision on this. I'm just trying to tell you why it is how it is and just how long it's been that way. This thread is hardly the first one to suddenly realize this is how GLib works and get upset about it. But GLib has always worked this way. There are other people you'd have to convince if you wanted to change anything. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Hi, On Mon, May 30, 2011 at 8:37 PM, Shaun McCance wrote: > But I want to point out that my point was never that GLib > should behave like a language with exceptions. Just that > it should let bindings in those languages behave like they > should. I agree that would be ideal if you were optimizing for non-C. But the only way to do that is to replicate the entire API currently lacking an error indicator, with a second _with_error version of every function. Some functions may happen to have some other ad hoc way to do an error (like returning NULL) but it'd just be some subset without rhyme or reason. If you aren't prepared to do the _with_error() replication of the API, then doing it here and there at random is kinda weird. Either it's needed or not, it isn't needed here and there at random. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Hi, On Mon, May 30, 2011 at 8:17 PM, Morten Welinder wrote: > Doing a g_return_val_if_fail is fine here. That will give the user a > chance of saving his work. This is in contrast to g_error which is a > sure way of eating data. If that's the argument it's fine. I treat return_if_fail and g_error the same (often setting the env variable to make return_if_fail crash). Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Hi, Man, how many times has this thread happened? At least fifty. On Fri, May 27, 2011 at 10:57 AM, Shaun McCance wrote: > try: > load_some_extension() > except: > warn("This extension sucks. I'm disabling it and moving on.") > > Of course, GLib is C. We don't have exceptions. We have GError, > which is a decent foundation for exceptions in language bindings. > But if we don't use it, then languages that could otherwise do > the right thing are screwed. This is the core thing. People who expect no g_error/abort are used to languages with exceptions. The thing that's different about C is that an "exception" (think GError) changes the function signature of that function... _and_ *all callers* in any library or app! One of the very foundational design decisions of GLib, back in the 90s, was to not have an error code from every single function. (Contrast with some other utility libraries.) And this decision has been continued in GTK+ and all the other family of GLib-based libraries. Some might like to change it, but people, it's too late to paint this bikeshed another color with thousands and thousands of existing API calls relying on it. It does, you have to admit, make the C API a lot nicer. The core principle that allows most functions to "always succeed" is that programming bugs are not "thrown," they just terminate the program. Config schemas that contain type checking and default values are part of the program; the program is either incorrect, or redundant in a way likely to create bugs, without the schemas. If schemas were just docs or something, it would be a different situation. If you really want to "handle" this, make it impossible to be missing the schema, by embedding the schema in the binary at compile time, perhaps. I don't know. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: align vs expand vs grid
Hi, On Thu, May 12, 2011 at 9:53 PM, Benjamin Otte wrote: > Don't assign any extra space to children, use it as space on the > right/bottom side. (This is the current behavior) This seems screwy, unless the grid has left/top alignment set. I would expect the grid to position the children according the alignment set on the grid (center children as a whole if grid is aligned center, etc.) - this should Just Work because the grid layout code should not work with an area exceeding the children's natural size if the grid isn't set to FILL and the children aren't expanding. > And I think this principle is wrong. First of all every other > container (that is not considered for deprecation) does assign extra > space to children (in particular all subclasses of GtkBin do, such as > GtkWindow, or GtkExpander). GtkBin only assigns extra space to children if align=FILL on the bin, right? This is just an attempt to interpret "scale up the widget content to fill the area," by passing the buck down to the children of the bin. > Second, if children should never get > assigned extra space, why do we have the ALIGN_FILL parameter? You'd use FILL to say that the child, once expanded, should somehow grow its content (e.g. by scaling) rather than just centering (or left/right-aligning) its content by adding blank space. > Third, > if the grid decides where to put the extra space, the align property > does not ever make sense The align property should determine whether the grid's layout code even sees extra space. If it isn't FILL, then it should just be looking at a natural-size-sized area on the start/end/center, I'd think. > Fourth, 2 interesting invariants hold for a Grid with one > child: 1) It behaves identical to all bin subclasses and 2) it does > not modify the layout at all. If you set align=center on a Bin then say the frame in GtkFrame should not fill extra space, it should be centered. The only difference with GtkGrid I think is that you have an alternative potential interpretation of FILL, which is to add spacing amongst children, instead of passing through to children. But I do think Grid should match Bin in that it shouldn't add space *around* the children in order to implement FILL. What I was arguing in https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00072.html I guess is that adding spacing is more useful than passing through to the children, since you can set the children to expand if you want pass through to children, while adding the spacing is an otherwise-unavailable feature. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: align vs expand vs grid
Hi, On Fri, May 13, 2011 at 12:00 PM, Matthias Clasen wrote: >> Second, if children should never get >> assigned extra space, why do we have the ALIGN_FILL parameter? > > expand is about whether you _want_ the child to receive extra space. > align=fill is about how the child should react if it _gets_ extra > space, wanted or not... > I agree with this, that's exactly how I would have answered. A widget can get extra space without having expand=true, say for example it's in a container that forces all children to be the same size. expand means "extra space is useful" while align describes how to handle the extra space. If you think of an image widget, maybe centering the image and scaling the image up to fill the space would both be useful behaviors, depending on the app. So you could use align=CENTER or align=FILL. Something like that. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: decrease widget show time
czk, another thing you'll need to do to get useful results is run a lot of iterations. If you get this all going in a loop then you can run sysprof for a while to get enough data. I would try to keep running for 20-30 seconds. To see one-time startup initialization, your loop will have to keep relaunching the app (rather than just reshowing the window in a single process). Havoc On Fri, Mar 25, 2011 at 11:35 AM, czk wrote: > Thanks, I ever use oprofile, but it didn't help me much. May I to try > sysprof. > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
Hi, On Sat, Feb 26, 2011 at 9:35 AM, David Zeuthen wrote: > but if someone writes a nice dbus-daemon(1) patch, we > would probably accept it, right? > I suppose... if they had enough test coverage to prove it actually worked ... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
Hi, On Fri, Feb 25, 2011 at 9:13 PM, Wen-Yen Chuang wrote: > > I suppose GtkApplication users do not need to handle dbus directly. > > So if GtkApplication can handle dbus restart / dbus crash, I may also > consider using GtkApplication for single instance app. However, the whole restart issue and those debian discussions you linked to don't really apply to GtkApplication, because it uses the session rather than the system bus, as far as I know. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
Hi, On Thu, Feb 24, 2011 at 8:51 PM, Wen-Yen Chuang wrote: > a.) restart dbus daemon (and keep everything communicating to dbus > still working) is not supported by upstream in a sensible way. > [1][2][3][4] upstream doesn't support this because it isn't a dbus issue. The problem is that no apps handle restart. So upstream's advice is, don't restart, because apps won't handle it. If you want to fix all the apps, you can do so. There are no dbus-daemon changes required. (fwiw, g_bus_own_name() in gdbus could in theory make it considerably easier to handle bus restart, assuming gdbus itself handles it.) The reason apps don't handle it is because this is a very hard thing to handle and requires per-app work. You'd have the same problem with any stateful IPC protocol. (You can build stateless protocols on dbus if you like, that will have no issue.) Anyway, the upstream position, or at least my opinion, with respect to the system bus, is "restarting won't work in practice because you can't rely on apps handling it" rather than "apps should not handle it." If apps handle it that's great. The links you mention are just a bunch of confused people blaming the protocol, when the issue is the missing logic in apps. With respect to the session bus, the bus exiting is supposed to end the session, so in that case exiting has special meaning and apps should not try to survive it. The same is true of gnome-session for example. But still, that is a case of policy decision for what apps do, and has nothing to do with dbus-daemon or the dbus protocol. > b.) dbus can not be used over network > You have to setup a proxy for dbus to use it over network. You can enable TCP if you have shared network homedirs and it ought to work. If you don't have shared homedirs you would have to add support for another auth method, something that nobody has done yet, but anyone is certainly welcome. For some applications, you may also be able to use anonymous auth (i.e. no-auth mode). Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Shrinking and growing widgets in GTK+ 3.x
Hi, It seems like the following would work but maybe I'm missing the obvious * have the video request natural size = its natural unscaled size, and min size of whatever lowest scale factor you want to allow * to snap to natural size, just size request the entire toplevel to get the natural size, then gtk_window_resize() to that size Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How can i learn the design architecture of the gtk+ multiline text edit?
This document may help you: http://git.gnome.org/browse/gtk+/tree/docs/text_widget_internals.txt Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Can I get a quick overview of GtkApplication actions?
Hi, On Mon, Nov 1, 2010 at 2:25 PM, Matthias Clasen wrote: > > In fact, here it is: > http://library.gnome.org/devel/gio/2.27/GApplication.html#gapplication-example-actions Was a bit confused reading this example, what are the hold/release in the action callbacks about? Would they only be needed if someone runs the main loop in the callback? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
Hi, On Mon, Nov 1, 2010 at 2:10 PM, Peter Clifton wrote: >> Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code. > > Much as I am a fan of self-documenting code.. isn't "* 1000" much > shorter and easier? Well there's already G_USEC_PER_SEC but I guess it's saving typing of more zeroes. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
Hi, On Mon, Nov 1, 2010 at 1:06 PM, John Ralls wrote: > I don't see any reason to have a replacement for GDate. fwiw, the original (and possibly only) use of GDate was for security price data (Open/High/Low/Close), which has only a day, not a time or timezone. This is also why GDate is not opaque, because it was important to be able to allocate a huge array of GDate quickly. Not that this makes GDate something that should be in a general-purpose lib like GLib, but it is a use-case that I'm not sure GDateTime would cover. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
Hi, On Mon, Nov 1, 2010 at 12:06 PM, Ryan Lortie wrote: > The conclusion of all of this is one point: barring substantial > complaints, the be-all and end-all of time in glib is going to be > microseconds stored in a gint64. Your arguments sound right and a nice upgrade over current APIs. Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Doubts about GPeriodic
Hi, On Sat, Oct 23, 2010 at 3:37 PM, Owen Taylor wrote: > - We should not start painting the next frame until we are notified > the last frame is complete. Does frame-complete arrive when "we just did the vsync" i.e. last frame is just now on the screen? We can dispatch "other stuff" while we wait for this, right? Does the time between sending off the buffer swap, and getting the frame complete back, count as time spent doing other stuff? I guess that would roughly mean "if paint finishes earlier than it had to, get ahead on other stuff in the meantime" - the wait-for-frame-complete is a way to take advantage of any time in the 50% designated for painting that we didn't need. I mean, presumably while waiting for frame-complete the main loop is going to run, the question is just whether that time gap factors into any of the time calculations. > paint time other time fps work fraction > == == === = > 1ms 15ms 60 94% > 8ms 8ms 60 50% > 10ms 22ms 30 68% > 17ms 15ms 30 47% > 20ms 12ms 30 38% > 24ms 8ms 30 33% > 40ms 10ms 20 20% > 55ms 11ms 15 20% > 90ms 10ms 10 10% > > But what this does mean is that there is a cliff across different > systems here that's even worse than it looks from above. Take a very > non-extreme example - if I'm testing my app on my laptop, maybe painting > is taking 20ms, and I'm getting a reasonable 30fps. I give it to someone > with a netbook where CPU and GPU are half the speed and painting takes > 40ms. The framerate drops only to 20fps but the time for a background > operation to finish increases by 3.8x. The netbook user has half the CPU > and we're using only half that half to do the background work. Good breakdown, a detail, at some point animations are just unusable. I think you need a pretty smooth / reliable 15-20fps-ish for an animation to be even worth doing, really. If you average a rate like that but have some big hang at the start or end, or if you average a really bad rate like 5-10fps, my experience is that people say "this is slow and sucks" and also the animations don't usually achieve the UI feedback goal because people don't perceive motion, they perceive an annoying artifact. I don't know exactly how to deal with that. It doesn't really matter for the tree view thing, that's not an animation. But I do wonder if we could automatically make an animation drop all frames, if it's only going to have 4 frames anyway, or whatever. I guess this is a side issue / additional elaboration. > So, there's some appeal to actually base it on measured frame times. > Using just the last frame time is not a reliable measure, since frame > painting times (using "painting" to include event process and relayout) > are very spiky. Something like: I had awful luck with this. (I did try the averaging over a window of a few frames. I didn't try minimum.) It's just really lumpy. Say you're transitioning from one screen to another, on the first frame maybe you're laying out the new screen and uploading some textures for it, and then you have potentially very different repaint times for the original screen alone, both screens at once during transition, and the final screen. And especially on crappy hardware, maybe you only get a few frames in the whole animation to begin with. Minimum might be more stable than average. Another issue with animation is you don't know the average until you're well into the animation. Now in the tree view case, rather than an animation case, I'd expect very uniform paint times. Here's a direction of thought: do things differently when there's an animation active vs. when we're doing a "regular" paint. litl shell actually does track this. The problem with it (maybe obviously) is if you have any continuous/persistent animations. > - Average time over last three frames > - Minimum time over last three frames > - Average time over last three frames where only motion events were > delivered I wonder if some kind of synthetic benchmark would end up working more predictably. Sort of like that "performance score" Windows will compute for you. Maybe they even store that somewhere and base stuff on it, who knows. Though as long as we're only using this for a *max* time to do "other stuff," rather than setting a timeout or simply blocking, it isn't exactly the end of the world if we get this wrong. > Basically yes. I can't see us ever doing video in gnome-shell - we just > have to be able to smoothly composite video someone else is playing. (to be clear, that's what we do also.) > But I'm not really thinking about gnome-shell here, I'm really thinking > more about a "standard" application perhaps Evolution or Rhythmbox. > Whether written in GTK+ or in Clutter or some hybrid. Agre
Re: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 9:56 PM, Paul Davis wrote: > you guys are working out an incredibly complex and potentially baroque > solution when the elegant and arguably "correct" one has already been > implemented several times in different contexts. what's the point? > There's a lot of text in this thread but I think the resulting code at issue is not large, dev time measured in days. Well what we're arguing about is just a small patch once there's a paint clock. The paint clock itself somewhat larger but still hopefully days. (Developer days not calendar days.) We have significant prior art (clutter master clock, litl shell, gnome shell, etc.) so it isn't from scratch, that's part of why people have stuff to say about it. Heck I'm sure Ryan has already finished the thing while we're discussing it here. Changing over to having threaded rendering and GL-composited layers is comparatively huge by 10x or 100x I would think, and hasn't even been prototyped out by anyone. I could be wrong, as I said I haven't tried to work it through other than idly thinking about it a little. Maybe there is a simple version. An important problem is more or less addressed by just the paint clock, which is to be able to sync to hardware refresh and have a tween timestamp related to that syncing. It's possible to get smooth animation by just adding the paint clock. As a practical matter what I'm going for is to get GTK to be sensible when in-process with Clutter. The other stuff I listed at http://log.ometer.com/2010-10.html#18 is part of that too. I just feel like it sucks to continue the "to use Clutter you have to reinvent all the GTK wheels" situation until GTK 4 and that it might not be such a huge task to make GTK behave itself. It may be that a possible approach to a render thread is to have clutter in one thread and GTK in another thread layers are clutter actors that GTK renders to... just idly thinking again ;-) honestly I have no idea how all this should work. Another question that keeps popping up for me is why each process should have its own compositor and then there's also an X compositing manager. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 4:48 PM, Owen Taylor wrote: > I think we're largely agreeing on the big picture here - that priorities > don't work so there has to be arbitration between painting and certain > types of processing. Right, good. The rest is really just details - there are various ways it could work. As I wrote this email I realized I'm not 100% clear how you propose the 50/50 would work, so maybe it's something to spell out more explicitly. There's no way to know how long painting will take right, so it's a rule for the "other stuff" half? Do you just mean an alternative way to compute the max time on non-painting tasks (half of frame length, instead of 5ms or "until frame-complete comes back")? > But pathological or not, I think it's also common. This is where my > suggestion of a 50% rule comes in. It's a compromise. If we're lucky > repainting is cheap, we're hitting the full frame rate, and we're also > using 75% of the cpu to make progress. But when drawing takes more time, > when there is real competition going on, then we don't do worse than > halve the frame rate. > > (This continues to hold in the extreme - if redrawing is *really* slow - > if redrawing takes 1s, then certainly we don't want to redraw for 1s, do > 5ms of work, redraw for another 1s, and so forth. Better to slow down > from 1 fps to 0.5fps than to turn a 1s computation into a 3 minute > computation.) Let me think about this in terms of litl shell, which is the real-world example I'm thinking of, and maybe we can see how gnome-shell or some other GL-using apps differ which could be instructive. Just to go over what's in there, you have your compositor; the most intensive painting it does would usually be repainting video. But also just has various GL eye candy animations and it has a lot of clutter actors on some screens, so that takes time. Since lots of UI is in the shell itself, compositing is not always what we're doing, sometimes just a regular Clutter app really. Then crammed into this process, for better or for worse: - "UI chrome" for out-of-process browser (toolbar in-process, actual web page out) - global UI chrome (settings, switching between apps, etc.) - video chat stuff mixed in to the overall UI (the video chat engine and video/audio playback is out of process, but has a lot of chit-chat with the shell, it isn't an "app" but mixed into the global UI) - photos app that downloads photos from web then does GL-ish stuff to display them (this is in process for the bad reason that drivers are broken and out of process GL is/was fail) - playing audio bleeps and bings in response to UI interaction - chatter with a sqlite thread - chatter with the litl servers (over dbus, via the browser process) - chatter with gio threads - chatter over dbus about NetworkManager and whatnot - chatter over dbus to GTK widgets that are out of process (don't ask but guess why I'm interested in certain GTK work ;-)) - "misc" I guess gnome-shell is similar except less "stuff" As you say in the followup mail, at some point multiple processes/threads exist for a reason. Agreed, but in litl shell there's only one thing I think is in-process that shouldn't be, which is the photo app, and one thing is out of process that shouldn't be (GTK widgets). It's just a complex app talking to a lot of other processes. All the main shell really does is coordinate processes and paint an assemblage of the other processes. I don't know, I would think it's basically the same deal as the "main" Chrome process with every tab out of process, or as the main Eclipse process where Eclipse has lots of threads, or whatever. The main shell doesn't do blocking IO or long computations. It does have loads of IPC queues to talk to all the threads and processes. I almost feel like the threads and processes are the whole reason we have queue-based GSource. It almost seems like this is my prototypical case, where there *isn't* any computation in the main thread, just lots of queues to dispatch, and the case you're worried about most is where there *is* ... ? On Radeon hardware with indirect rendering, litl shell paint takes in the 7-9ms area. So for 60fps (16.6ms per frame) you have about 5ms per frame leftover with a little headroom. On 50fps then you have more headroom. I'm not sure exactly what you're suggesting on the 50% rule; if it strictly said 8ms instead of 5ms for the non-paint half, then that sort of moves the practical numbers from "60fps with a bit to spare" to "dropping frames" right? Most likely it isn't genuinely that big of a deal because most frames don't hit the 5ms max, and even fewer would hit the 8ms max, and we can start painting once there's nothing to do. But there is sort of a qualitative difference between 5 and 8, which is whether the painting still fits in the frame or finishes too late. Ignoring the specifics, takeaways could be: * there's a cliff in the chosen time to spend not-painting where we make ourselves miss
Re: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 5:06 PM, Paul Davis wrote: > starting from scratch, and thinking about the parallels with a > pull-model realtime audio design, it seems to me that if you were > designing this entirely from scratch you wouldn't serialize painting > and other source handling. you'd double buffer everything and run the > paint/expose/vblank cycle in a different thread. whenever the > non-paint/expose/vblank threads were done with refilling a new buffer, > it would be pushed (preferably lock free) into a place where it could > be used by a compositor and blitted to the h/w during the > paint/expose/vblank iteration. > Right - Miguel pointed out to me (unrelated to this thread) that Mac and Windows both work this way these days, and I'd already been noticing that Chrome, new Pepper plugin API, lightspark, and probably other stuff all seem to be moving to a "build a stack of software-rendered layers then use GL to squish them" model. So building a bunch of layers (ideally in threads) then GL-compositing the layers (with optional transformations and shaders) seems to be kind of the thing to do these days. You can animate the layers and shaders totally in the GL thread without mixing up with the app code. It seems like a big hairy change though. I definitely haven't taken the time to start working it out. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 10:28 AM, David Zeuthen wrote: > If you believe that the GUI thread should never perform blocking IO > (such as reading from disk or IPC) or never perform CPU-intensive > tasks (such as image- or video-decoding) then... then all that your > code in the GUI thread does, is to receive data from one thread and > maybe signal another thread. This point only affects the "constant factor" though right, not the basic character of what's going on. If I have a spinner animation and that paints flat-out as fast as possible without a "yield gap" to let other sources run, then that _also_ starves a superfast main loop source that just sits there grabbing messages and then throwing them elsewhere, just as much as it starves a super slow main loop source. Speed is not the problem, it's whether the source runs at all. If you go the other way and want to starve painting if we're doing our fast message throwing, then you're relying on always processing messages faster than the other side can send them. Being "fast" is not enough; it has to be "faster," i.e. it has to catch up and empty the queue. In fact *all* active main loop sources have to happen to be caught up *on the same iteration*. So if you're emptying three queues you have stay ahead of all three senders at once and get them all to zero at the same moment, and only then can you paint. There's no special guarantee you can do that. You're relying on it happening to work out. Imagine two processes that are both following the rules and have 10 streams open to each other and they are both processing all 10 at a superfast rate just tossing messages back and forth. What's the latency between occasions where these processes have 0 sources to dispatch? That drives your framerate. While 10 streams between two apps sounds contrived, I don't think one big complex app with say a sound server and some downloads in the background and some other random main loop tasks is all that different. > Anyway, my point really was something like this: If you want to talk > about smooth animations and synchronoizing to vblank, it would > probably be good for GPeriodic, Clutter and GTK+ to specify what > people should and shouldn't be doing in the "GUI Thread" I know a > lot of it is obvious to people on this list but it never hurts to > write it down anyway. With my "finite-length yield gap in the paint loop" approach, I think you can do anything in the GUI thread as long as each single dispatch is fast (and bounded in time). So you can't block, but you can do anything that is _always_ pretty fast (you can't do things that are _usually_ pretty fast, such as drain an unbounded queue, or blocking IO that sometimes decides to hang for a bit). That's how I'd document it. The one thing that still breaks is if all your fast-dispatching GSource add up to not-fast, since we have to dispatch all or nothing at each priority. Solving that could be overkill though. File under "someday." With a yield gap, you need threads to block or to do an indivisible long computation, but you don't need threads just because you have a queue (or a divisible computation, which is basically a queue). In the more classic approach (paint priority stays constant regardless of time elapsed), I think you can do anything in the GUI thread as long as: - each individual dispatch is fast AND - (an animation is allowed to starve whatever you are doing indefinitely so you can be below paint priority OR - the sum of all dispatches that could occur in a single frame timespan is fast and bounded. No queues. Long computations are no good even if split up across dispatches. So you can be above paint priority.) it isn't clear that all long, but divisible, computations can be tossed out of the UI thread. "filling a Tree/TextView" is a good example of how "UI" vs. "not UI" is kinda fuzzy To avoid queues in the main UI thread, you need both source and sink to be threadsafe, and real-world unthreadsafe sources include say libdbus, real-world unthreadsafe sinks include say GtkWidget. One thing, it doesn't matter if paint priority is default or idle. The issue is created when it's fixed with respect to "other stuff," instead of changing priority dynamically. Anyway, yes, this only matters for a large complex app doing lots of stuff in the same process as painting, while also trying to avoid dropping frames. For any simple case, things just muddle through. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: threading / timers / etc
Hi, On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie wrote: > - We will add GTimeSpec which is GTimeVal using nanoseconds instead of > microseconds (same story with struct timeval vs. struct timespec). > The librt interfaces provide this level of accuracy so it would be a > shame to needlessly discard it. I know this is a completely minor side issue to the point of your email (which sounds good overall) but I often find myself writing a convenience wrapper around g_get_current_time() that returns a single integer. If you do get_time(TimeSpec*) it might be nice to also do a "uint64 get_time_milliseconds()" wrapper. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 10:24 AM, Owen Taylor wrote: > Is painting well behaved? Inherently - no. We can easily get in > situations where we can spend all our time painting and no time doing > anything else. That's the point of the up-to-5ms-of-dispatch thing (or the wait-for-frame-complete thing), though, right? We can force painting to be well behaved by having a period during each frame where painting is not ready for dispatch or has a lower priority. During that period anything else can run - even idles can run. (Or if we like, even default idles can run but not low idles, or only default priority not idles, could be implemented. Just has to be defined.) I don't see the need to choose between painting-starves-everything and everything-starves-painting. The "dispatch everything but painting" gap can have a max length, not a fixed length - if you do get everything else done you can proceed to paint. (Well, that's what we do with the 5ms. I guess it might be harder to do with a pure GMainLoop solution but you could do it, by having the paint source dynamically change its priority or by having a super-low-priority paint source that's always ready plus a high-priority one that is only ready when frame-complete or after an interval.) The effect of max rather than fixed length "everything else" gap is that if painting truly needs the whole frame interval (rather than interval minus gap), painting may still keep up on those frames where there's little else to do. The idea is there's a period in which painting will be well-behaved by yielding - it isn't allowed to defer everything else indefinitely / 100% of the time. This changes your max time you theoretically have to paint from 1/fps seconds to (1/fps - gap) seconds. However even if you can't paint in (1/fps-gap) you will only lose a frame due to the gap when there's really stuff to do inside the gap. And if you can't afford a reasonable gap you probably really are hosed anyhow. There is already a fixed max on paint time in order to look good, so that doesn't change, the max is just tweaked (and can flex up to the absolute max, 1/fps, whenever possible). The idea is that if your average paint-cpu and everything-else-cpu adds up to less than 100% cpu, we shouldn't need to drop frames. However with a starvation model, you drop frames even if you can keep up on average, due to lumpiness, right? so that's the idea of only yielding for a gap - if you get a lump in your everything-else, such as a flood of messages, try to spread it over a few frames. In practice I think that's what we're talking about. Say I have a spinner animating smoothly, and I get some flood of IO or dbus or whatever it is. Do I handle that flood in 30ms and my spinner hiccups, or do I spread the flood in chunks over several frames, and my spinner stays pretty. As an app developer I think what I want is the latter. But I also don't want to wait for the spinner to go away before handling this flood. I want to smooth the flood over multiple frames, but not defer it indefinitely, I want to make progress on every frame. I don't think that can be expressed by just having a fixed priority on paint and a fixed priority on my handler; there has to be some way in which the priorities "flip" during the frame. > Are IO completions and IPC well behaved? Well that's really up to the > application however, they have to be *somewhat* well behaved in any > case. What's hard I think is to make them well behaved in the aggregate and on every single frame. i.e. it's hard to avoid just randomly having "too much" to dispatch from time to time, then you drop 3 frames, it just looks bad. But as long as you're OK *on average* this can be solved by spreading the dispatch of everything else across more than one frame, instead of insisting on doing it all at once. If you aren't OK on average, that's a problem the app is just going to have to solve. > If I have a GIO async callback that fills a treeview, there is one > pathology where my callback gets called so frequently that we never get > get to repaint. But what may happen instead is that I get so much data > in a *single* callback that I block the main loop for an unacceptably > long period of time. So we always will have the requirement that > callbacks from the main loop must be *individually* short. Yes. I think things can be made to work pretty well with just this requirement. > Making IO > completions and IPC highest priority makes this requirement a bit more > stringent - it means that callbacks from the main loop must be *in > aggregate* short. That callbacks from the mainloop aren't allowed to do > expensive stuff, but instead must queue it up for an idle at lower > priority. A priority lower than paint is the right priority for most stuff, IMO, as long as we're going to dispatch that lower priority at least for some gap per frame. If the presence of an animation means that we aren't going to dispatch lower-than-paint sources unti
Re: Doubts about GPeriodic
Hi, On Thu, Oct 21, 2010 at 5:47 PM, David Zeuthen wrote: > Note that with GDBus the resulting GDBusMessage is actually being > built in a separate (and private) thread - so in practice there is > zero overhead in the GUI thread - in particular it doesn't depend on > what kind of message it is or how big the message is. The same is true > for most of libgio's file and networking primitives (e.g. > g_file_load_contents_async() will cause work to happen in a worker > thread etc.). I don't think this matters as long as there's effectively a queue in the main thread (i.e. each message or IO chunk has a handler in the main thread). If you dispatch once per dbus message from an X-priority main loop source, then lower-than-X-priority handlers will not run until there are no dbus messages available. So if you are getting flooded with messages, for example if a stream of data is being dbus-transmitted, you would need to chew through that whole stream - _or_ it would have to just happen that on one iteration of the main loop the message processing had caught up with the message sending and the queue was empty. Moreover that iteration would have to happen to have no other X-priority sources ready. In that case a lower-than-X-priority dispatch could occur. As the number of X-priority sources goes up (think big complex app with plugins) the odds of getting no X-priority sources on a given iteration would presumably drop. As long as the main loop is seeing a stream of items with no guaranteed pauses in the stream, in theory that main loop source runs unbounded. (yes, in practice it usually doesn't run unbounded, but I bet trying to hold 60fps will make the in-practice glitches more visible) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Doubts about GPeriodic
Hi, I guess a frame-complete signal (or timer) acts like the 5ms to create a window for other event sources to run? So painting should not starve other stuff, the mainloop could dispatch other stuff while the frame is being completed. Given a gap waiting for frame-completed you don't need a hardcoded 5ms (makes sense to me). Re: frame-complete, it of course assumes working drivers... If you don't have the async frame completed signal you may be back to the 5ms thing, no? I guess with direct rendering you are just hosed in that case... with indirect you can use XCB to avoid blocking and then just dispatch for 5ms, which is what we do, but with direct rendering you might just have to block. Unless you're using fglrx which vsyncs but does not block to do so (at least with indirect, not totally sure on direct). Sigh. The driver workarounds rapidly proliferate. Maybe clutter team already debugged them all and the workarounds are in COGL. :-P I guess COGL or whatever could in theory just send frame-completed after a fixed 5ms as a workaround on platforms that need it. There's also ARM and whatever platforms with no X to consider. Re: priorities, I would think once the frame-complete comes back (or 5ms expires, absent frame-complete) it's appropriate to drop everything else (unless it's explicitly asked to be super high priority) and paint. "paint" includes processing entire event queue and relayout, so that should have the UI sufficiently updated. You were talking about handling incoming IPC at higher priority than repaint... it sort of depends on what the IPC is about. For example, we have some that is UI-related, similar to events, and other that is basically IO. If you have a flood of IO coming in (say downloading a big file) then I don't think it's acceptable to wait for that queue to drain before painting - it could be minutes, not seconds. If you think about something like the dbus main loop source, the dbus library doesn't know what the heck is going to be coming in, and you can't tune the main loop source depending on what kind of message it is. Anything with a queue doesn't really have a bounded time within which its GSource won't be ready anymore. Threads only help if you can squish the queue in the thread... otherwise the unboundedness ends up in the main thread anyway. For example if you're reading a file, then if you can parse it and convert it to a small object in the thread, there's no potential paint starvation problem, but if you need to feed the whole unbounded dataset over into a TextView/TreeView, then there is (as you mention). I feel like most stuff should be below paint priority, not above, and then each frame should have a window (either "while waiting for frame-completed" or "fixed time like 5ms" or whatever) in which things below paint priority are going to run. That way things more or less can't break, as long as each individual dispatch() is reasonably fast/bounded. If most stuff is below paint priority (in order to ensure we keep up the frame rate), that could be implemented either by making most stuff an idle, or by making paint priority above default. "Most stuff should be an idle" is weird to me - seems to make default priority kind of meaningless and render g_*_add() etc. APIs useless. Why not make paint priority greater than the default priority, and so most things should be default, and idle is reserved for things that it's acceptable to starve? Conceptually, events+paint _should_ be highest priority - without those we are hiccuping and breaking interactivity - the only thing is, they can't run continuously, each frame needs a slice of doing "other stuff" and that could be a fixed interval, or given decent drivers, the time during which the GPU is chewing on the frame / waiting on vsync. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Doubts about GPeriodic
Hi, On Thu, Oct 21, 2010 at 5:46 AM, Ryan Lortie wrote: > > What about non-input events, though? Like, if some download is > happening and packets are coming in and causing dispatches from the > mainloop that we do not have control over. I brought this up a bit in the earlier thread. My takeaway is that for I/O type stuff you usually want what we ended up with at litl, which is to limit it to some length of time per frame. Unfortunately GMainLoop has no native way to do that. I described our solution a bit in the old paint clock thread. There's a danger both of some random download starving animation and of your download spinner starving the download. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Doubts about GPeriodic
Hi, On Thu, Oct 21, 2010 at 4:26 AM, Emmanuele Bassi wrote: > no, the GL context should *not* be per window. multiple GL contexts > usually pose more problems than they solve, in synchronization and > context switching, on basically all drivers - except maybe on nvidia[0]. Fair enough, I didn't realize it was actually possible to do one global context for all windows. I would still argue for per-window (so we can shut down unmapped/hidden windows and so widgets look at parent, not a global) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Doubts about GPeriodic
Another issue, seems like the ticker needs to be per-native-window: * the GL context is per-window so the vsync mechanism also is * we ought to shut down the ticker on windows that aren't visible * each screen has its own vsync and the window is the normal convention to imply a screen * the general principle that widgets should be getting context and state from parent widgets, in most cases ultimately from the toplevel - but by chaining through parents. Rather than from global singletons or state. attempted to explain in http://log.ometer.com/2010-09.html#19 (so any gtk widget that's a child of a clutter stage for example, would want to be asking that clutter stage for paint clock) Native windows would be either toplevels or embedded clutter/glarea widgets, generally. But maybe just saying "any native window can have its own clock" is right. There probably shouldn't even be a global API because using it would be broken, right? When not actually using GL or vsync, then I think all native windows could just inherit a single global ticker that would just be a timeout, but that's more of an implementation detail than an API thing. Another thought, in the patch periodic->last_run = now; I think this will look a little rocky - the frames are going to display at actual-screen-hz intervals, no matter what time it is when you record last_run and no matter what time it is when you call your drawing APIs. So things look better if you keep the "tween timestamp" on hz intervals. The last_run time probably has very little to do with when frames hit the display. Animations should go ahead and paint assuming they are hitting the display at a fixed fps. In the litl shell fwiw the pseudocode for the tween time on each frame is: int frame_time = 1000 / fps; int actual_time = - current_ticker_time; int frames_late = (actual_time / frame_time) - 1; current_ticker_time += frame_time; if (frames_late > 0) { current_ticker_time += (frame_time * (frames_late + 1)); } The idea of this is: decide to drop frames based on floor(frames_late) and then skip ahead by ceil(frames_late). The point of that is to bias against dropping a frame until we're a full frame behind, but then be sure we drop enough frames to get ahead a bit when we do drop them, and always stay on a multiple of the refresh rate. Due to this and also the desire to not explode when the computer's clock is set, I would define the ticker to be a monotonic value that is in time units but is not a wall clock time. i.e. if I change my computer's clock back an hour, the ticker should keep marching forward, and the ticker is allowed to be fudged to make animations pretty. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Docs for the gtk-style-context branch changes
Hi, On Tue, Oct 19, 2010 at 7:49 AM, Carlos Garnacho wrote: > * There is no intuitive replacement for gtk_widget_modify_*(). If we are > to drop GtkStyle, I think that 3rd party libraries and apps implementing > widgets could define regions and attach a GtkStyleProvider with the > fallback priority to theme these, this way themes and users' CSS have an > oportunity to theme these differently if they want, although others I've > talked with think gtk_widget_modify_*() is handy API that shouldn't go > away. I think what's important here is that there's a quick/easy way to "just set the color" on the widget. Both the "foreground" and "background" color (currently you have to know if fg is "text" or "fg" of course but no need to preserve that distinction afaik) The reason for modify_* was to fix this FAQ: http://ometer.com/gtk-colors.html That page still gets a fair bit of traffic from google, fwiw. As long as you keep that FAQ from coming back (i.e. have some reasonably obvious single-function-call way to "set the color of this text or background") it ought to be fine. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom wrote: > > What happens when another subclass wants to use > ->adjust_size_allocation() to realign itself further ? how > can it cooperate with GtkWidgetClass and not cause bad side > effects ? In the patch I posted (assuming the FIXME is fixed), what would still be broken? I'm sort of lost what problems are unsolved. Granted, I might find out if I tested the patch ;-) > ... and more importantly, why is this useful > to anybody except GtkWidget and GtkContainer ? It is useful in any abstract base class that wants to provide "stuff around" whatever its subclasses draw. I think GtkContainer is actually a good enough reason to have this. border-width is deprecated sure, but it's not going away soon, it'd be nice to clean up all the code that has to deal with it. Another example in GTK is GtkMisc, though we want to deprecate that too, you could use this vfunc to delete the align and pad handling from its subclasses and delete some code, which would be nice. Hypothetically you could do things like: * a base class that aligned in a more precise way than left/right/center (like GtkAlignment) * a base class providing more complex CSS-like border/margin/pad capability with colors for each * a base class that provided a frame * a base class that adds any kind of display or status next to subclass content All of these could also be implemented as a container, granted. (That is, GtkMisc and GtkAlignment solve the same problem.) However, I think there can be good reasons to do this stuff in a base class so your widgets can have the stuff "built in" Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, Here's roughly what I'm thinking about. This is an untested patch with a big FIXME in it (FIXME must be fixed to have a hope of working). But I thought since you were poking at this I better share sooner than later. Maybe there is some glaring problem here but just wanted to communicate the code I was trying to describe. One test of having this right is that it should be possible to make GtkMisc work with adjust_size_* and rip manual align and pad handling out of its subclasses. Of course, the implementation of GtkMisc would look a lot like the code in GtkWidget's adjust_size_* but since you could then "stack" Misc and Widget align and pad, it'd be a sort of torture test. Havoc diff --git a/gtk/gtkcontainer.c b/gtk/gtkcontainer.c index 30930e0..ba398f2 100644 --- a/gtk/gtkcontainer.c +++ b/gtk/gtkcontainer.c @@ -327,7 +327,10 @@ static void gtk_container_adjust_size_request (GtkWidget *widget, gint *minimum_size, gint *natural_size); static void gtk_container_adjust_size_allocation (GtkWidget *widget, - GtkAllocation *allocation); + GtkOrientation orientation, + gint*natural_size, + gint*allocated_pos, + gint*allocated_size); static gchar* gtk_container_child_default_composite_name (GtkContainer *container, GtkWidget*child); @@ -1805,22 +1808,26 @@ gtk_container_adjust_size_request (GtkWidget *widget, static void gtk_container_adjust_size_allocation (GtkWidget *widget, - GtkAllocation *allocation) + GtkOrientation orientation, + gint *natural_size, + gint *allocated_pos, + gint *allocated_size) { GtkContainer *container; int border_width; container = GTK_CONTAINER (widget); - parent_class->adjust_size_allocation (widget, allocation); + parent_class->adjust_size_allocation (widget, orientation, +natural_size, allocated_pos, +allocated_size); if (!GTK_CONTAINER_GET_CLASS (widget)->handle_border_width) return; border_width = container->priv->border_width; - allocation->width -= border_width * 2; - allocation->height -= border_width * 2; + *allocated_size -= border_width * 2; /* If we get a pathological too-small allocation to hold * even the border width, leave all allocation to the actual @@ -1830,22 +1837,14 @@ gtk_container_adjust_size_allocation (GtkWidget *widget, * As long as we have space, set x,y properly. */ - if (allocation->width < 1) + if (*allocated_size < 1) { - allocation->width += border_width * 2; + *allocated_size += border_width * 2; } else { - allocation->x += border_width; -} - - if (allocation->height < 1) -{ - allocation->height += border_width * 2; -} - else -{ - allocation->y += border_width; + *allocated_pos += border_width; + *natural_size -= border_width * 2; } } diff --git a/gtk/gtksizerequest.c b/gtk/gtksizerequest.c index c3d0398..9ebb908 100644 --- a/gtk/gtksizerequest.c +++ b/gtk/gtksizerequest.c @@ -223,20 +223,58 @@ compute_size_for_orientation (GtkWidget *request, requisition_size = requisition.width; if (for_size < 0) -GTK_WIDGET_GET_CLASS (request)->get_preferred_width (request, &min_size, &nat_size); +{ + GTK_WIDGET_GET_CLASS (request)->get_preferred_width (request, &min_size, &nat_size); +} else -GTK_WIDGET_GET_CLASS (request)->get_preferred_width_for_height (request, for_size, - &min_size, &nat_size); +{ + int ignored_position = 0; + int natural_height; + + /* FIXME getting unadjusted natural_height here is going + * to be annoying... recompute it? pass it in? is it in + * cache? + */ + + /* convert for_size to unadjusted height (for_size is a proposed allocation) */ + GTK_WIDGET_GET_CLASS (request)->adjust_size_allocation (widget, + GTK_ORIENTATION_VERTICAL, + &natural_height, +
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, I would think of it like this maybe real_adjust_request(orientation, &request_data) { adjust_request_by_adding_margin(orientation, &request_data) /* alignment does not affect request */ } real_adjust_allocation(orientation, &allocation_data) { adjust_allocation_by_removing_margin(orientation, &allocation_data) adjust_allocation_by_aligning(orientation, &allocation_data) } I think allocation_data *includes* the natural size, which is itself adjusted. So when you by_removing_margin you are dropping down the natural size you started with so that the align stuff has the marginless size. Same for for_size. Conceptually GtkWidget contains two adjustments. But those two adjustments should not have anything to do with each other. It's as if you had a hierarchy like: GtkWidget -> GtkWidgetWithMargin -> GtkWidgetWithAlignment Those would chain up to each other. But since it's all in one class the two adjusts are invoked inline. However if our adjust vfunc has the right signature, it should be possible to do margin and alignment orthogonally. On Sun, Oct 17, 2010 at 5:36 AM, Tristan Van Berkom wrote: > - Strip any padding added by itself and any subclasses from the > allocation->width (this produces a 'stripped_allocated_width') Widget base class need not strip what subclasses added - each subclass strips its own. When overriding, subclass has to chain up so widget can do its stuff just as container does. I'd also say "margin" here for clarity rather than padding > - If halign != FILL, it needs to limit the width to the real natural > size, this in itself involves: > > a.) calling gtk_widget_get_preferred_width() > I think get_preferred_width should be called outside of the adjust vfunc, and then initial natural size passed in. As the adjustment proceeds, the natural size is chopped down by each adjustment. > b.) stripping any padding from the returned natural width > (producing a 'stripped_natural_width') This should be done by the adjust_allocation_by_removing_margin() and the natural width that then gets passed for aligning would be reduced. > c.) interior width available for alignments becomes > MIN (stripped_allocation_width, stripped_natural_width) Hmm this doesn't sound right. Conceptually we have to decide if the margin is inside or outside the alignment-required padding. This basically means whether we do the margin adjust first or the align adjust first. (Note that on request you go from inner adjust to outer, i.e. chain up last, and on allocation the other direction, i.e. chain up first. So if margin is on the outside, it would be added second in request, and removed first in allocate.) Anyway. What should come in to adjust_allocation_by_aligning(&allocation_data) should be a natural size de-margined and an allocation also de-margined. We just align the de-margined natural size in the de-margined allocation. > - Now that we have the proper width for interior allocation; go ahead > and strip any padding added to the allocation->height, i.e. get > a 'stripped_allocated_height'. I think you go back and have your unadjusted width allocation, and you pass that as the for_width to the adjust_allocation(orientation=height). Now as the allocation adjustment proceeds, each adjust step has to also adjust for_width (in addition to the allocation itself and the natural size). > Of course furthermore, gtk_widget_get_height_for_width needs to be > amended to adjust the for_width by: > > - Stripping any extra padding added by ->adjust_size_request from > the for_width. Rather, each adjust_size_allocation "step" (align, margin, border_width are 3 "steps") should compensate for itself in the for_width as the chaining up proceeds. > That's the big picture of "what needs to happen", however it's still > not mapped to any proper API... I've been tentatively writing some > pseudo code that should do it but I keep getting stuck somewhere. I think just adding the natural size, for_size, and orientation to the existing two vfuncs should work. Probably need a struct to hold { size, natural_size, for_size } which are the three things to adjust. > There's also another alternative, all of this alignment/padding code > so far belongs to GtkWidget (and marginally GtkContainer), so does all > of the size-requesting logic... so we could go the direction of: > > - remove vfuncs ->adjust_size_allocation/->adjust_size_request I think the adjust approach should be workable as described above and keep the nice encapsulation / flexibility of the vfuncs. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, On Fri, Oct 15, 2010 at 11:32 AM, Havoc Pennington wrote: > > Without trying to code it and see if it works, it could look like: > > (* adjust_size_allocation) (GtkWidget *widget, > GtkOrientation orientation, > gint *for_size_opposite, > gint *natural_size, > gint *offset, > gint *adjusted_size); > > where all four numbers are changing as we're chaining > Widget->Container->Button > > Might be nicer to do struct GtkAllocatedSize { int for_size_opposite; > int natural_size; int offset; int adjusted_size } ? > > Sorry I got this wrong in my original patch :-/ > A nice cleanup this could enable would be to just do the alignment and margins completely separately in gtkwidget.c. i.e. gtkwidget.c would effectively have two adjustments. real_adjust_size_allocation(widget, orientation, allocated_size) { adjust_allocation_margin(widget, orientation, allocated_size); adjust_allocation_alignment(widget, orientation, allocated_size); } and same for request. i.e. "stack" the adjusts here, just as Container stacks on Widget Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, I think I get what you're saying. If not I'll probably understand it reading your code. btw things are looking kind of messed up to me in the current code in gtkwidget.c ... this: gtk_widget_get_preferred_width (widget, NULL, &natural_width); get_span_inside_border_horizontal (widget, aux_info, allocation->width, natural_width, &x, &w); so natural_width has the margins in it, right? But it's centered without removing those margins first. The code up in get_span_inside_border() removes margins from allocation->width but not natural_width. It seems like we need to remove the margins to get adjusted_natural_width. And then say in GtkContainer, we need that adjusted_natural_width and we remove border_width from it, and then we pass the twice-adjusted natural width with both margins and border width and alignment-added-padding stripped down to the actual subclass like GtkButton. Without trying to code it and see if it works, it could look like: (* adjust_size_allocation) (GtkWidget *widget, GtkOrientation orientation, gint *for_size_opposite, gint *natural_size, gint *offset, gint *adjusted_size); where all four numbers are changing as we're chaining Widget->Container->Button Might be nicer to do struct GtkAllocatedSize { int for_size_opposite; int natural_size; int offset; int adjusted_size } ? Sorry I got this wrong in my original patch :-/ Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, On Fri, Oct 15, 2010 at 9:55 AM, Havoc Pennington wrote: > I think you should just call the request methods again. (Not the > wrappers of course, the vfuncs directly.) Instead of passing in a > natural size. > I guess this doesn't work when chaining up and down Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, On Fri, Oct 15, 2010 at 8:55 AM, Tristan Van Berkom wrote: > The for_size fed to widget implementations additionally needs to > strip the added padding that can happen in ->adjust_size_request() Right, adjust_size_allocation should basically invert anything adjust_size_request does so the widget is seeing things as if only the widget itself had set the request. By "padding" I don't just mean the margin properties, I mean anything adjust_size_request adds (also the padding for fill alignment, the container border width, etc.) > However the bug I'm referring to is another one; the for_size also > needs to be limited to the natural size in the case that the widget > does not "fill" (i.e. not to compensate for pixels stripped in > ->adjust_size_request(), but for pixels that will further be stripped > in ->adjust_size_allocation(), in the case that the widget expanded). Wouldn't it fix this to do adjust_size_allocation on the for_size? > In the end the adjust_size_allocation() api/vfunc > will look like this: > > void gtk_widget_adjust_allocated_size (GtkWidget *widget, > GtkOrientation orientation, > gint proposed_size, > gint natural_size, > gint *offset, > gint *adjusted_size); If you have a for_size (which can be -1 for unset) then you could skip the natural size and just call the size request API again, using the for_size if >= 0. I think that would be better, because as you say: > The part that feels weird here is that we are feeding in the > natural_size, however it's important because come allocation time > specifically; the 'natural_size' may be in context to a for_size > in the other orientation (i.e. the widget cannot be expected to > just "know" its natural size in this stage). I think you should just call the request methods again. (Not the wrappers of course, the vfuncs directly.) Instead of passing in a natural size. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
In sounds like in short the for_size somehow needs to be adjusted (strip out the pixels that adjust_size_request added). (If I'm understanding properly.) Of course that's what adjust_size_allocation does, except it's both dimensions. for_size is after all the proposed allocation size in one dimension. Maybe just change adjust_size_allocation to take a GtkOrientation and return a single integer (could have a convenience function to do the current full GtkAllocation adjust). Then use that to clean up for_size when it comes in to compute_size_for_orientation() in gtksizerequest.c. Or I think for now it'd also work to make a GtkAllocation allocation = { MAXINT, for_height } and adjust that, seems less hacky to change adjust_size_allocation to be able to do just one dimension. I don't think a solution that looks at xalign specifically is needed, so we can keep the abstraction barrier. The generic mechanism just needs to be smart enough to know that the for_size is a proposed (adjusted up) allocation and thus has to be unadjusted before computing the unadjusted request. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington wrote: > d) max size widget can do something useful with > e) size at which widget acts like expand=false (this is what I'd call > "max size" and I think it's a feature GTK doesn't have right now) Trying to think about how these two are different, and not really getting anywhere. It seems like you'd never set the max size above the natural size. So in the scrolled window case, to get the effect Matthias was going for, maybe the answer would just be to set the max size hint on the window to the natural size. The problem with that is basically maximization and fullscreen, i.e. that we don't really want a max size - it's better to add padding. Conclusion perhaps, e) is not useful, user should always be able to resize "too high" and get extra padding in the layout, if they want. The situation where it could make sense to add max_size to get_preferred_{width,height} might be if the natural size were defined as c) "a good size", then you'd also be able to use a separate "max useful size." For example then a box layout would first bring all children up to the good size; if still extra space, then bring them all up to max size; if still extra space, then start padding them. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Tue, Oct 12, 2010 at 12:09 PM, Owen Taylor wrote: > I think you need to think very carefully about how natural width is > explained and documented, since it seems to be neither exactly: > > - the maximum useful width > - a "good width" for the widget > > I get the impression from the above that the main point of natural size > is that once a widget reaches it's natural size it will stop competing > with other widgets for space? conceptually and in ascending pixel size I think there could be: a) min size widget can be without breaking (breaking = drawing outside bounds or whatever) b) min size widget can be while being useful (still show some recognizable info such as at least one word) c) a "good size" d) max size widget can do something useful with e) size at which widget acts like expand=false (this is what I'd call "max size" and I think it's a feature GTK doesn't have right now) Coincidentally Matthias was just trying to invent e) on scrolled window by dynamically changing expand flag (see https://bugzilla.gnome.org/show_bug.cgi?id=628902), that just won't work afaik, but we _could_ in theory add a max_size to get_preferred_{width,height} which would do this at the cost of making size request more complex to implement. At the moment I'd say min size should be b) and natural size should be d), but maybe there is a solid argument for c). I tend to think c) should be done at GtkWindow or application level. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Tue, Oct 12, 2010 at 11:40 AM, Tristan Van Berkom wrote: > And currently the "min useful" is just not defined as > "a single word width". > Understood, I think we basically agree. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Tue, Oct 12, 2010 at 11:20 AM, Tristan Van Berkom wrote: > I'm not sure what exactly you are talking about here, the only guess > a label currently makes is for a reasonable "width-chars", i.e. limiting > a wrapping label to a reasonably large minimum width. This is to avoid > unreasonably large heights in proportion to the width. search for guess_wrap_width in gtklabel.c, that's what I mean, i think it's the same thing you're talking about. That sets min size I guess, but I'm also saying we should have natural size be max useful size, not another guess (related to earlier discussion). Basically I don't think min or natural should be a "guess what looks good," they should be true min and max useful size. > b.) letting the user shrink the window's width too small and grow the > window's height too much (if we were to constrain window size > dynamically) "too small" and "too much" here just means "somewhat unaesthetic aspect ratio" rather than "broken." If the user wants to resize to that, fine. Maybe their screen is a weird size. We shouldn't default to it though, which is why GtkWindow needs more smarts. If min size is two words per line instead of one word, ok, but philosophically the min size should be the minimum size that's remotely useful - NOT "size that looks pretty good" or "guess at a nice aspect ratio" Essentially, I don't think individual widgets should have much smarts about this stuff. They should just report min remotely useful size, max remotely useful size. Toolkit or app need to take steps to then make the overall layout look good. > Please explain where we are second-guessing stuff and how exactly > the toolkit is broken, then we can move on to fix it. I'm saying if the label needs any intelligence then we have a problem because any other widget using h-for-w would also need intelligence, and those heuristics may not even be compatible with each other or make sense in the overall layout. Widgets should just be dumb about this. Report their min and max useful size. > So far the two things I would change (or add as enhancements) are: > a.) Add a feature to let the GtkWindow choose a default size > according to the natural size clamped into the screen size > b.) Try making the window's height constraint contextual to > the window's allocated width. Yep I agree > I wouldn't say the toolkit is broken just because we haven't yet > added those features. If making Label "dumb" (just reports min and max useful size) has bad results, then that's a bug in the toolkit, or at least the app, or some widget with more contextual knowledge like GtkDialog. There isn't enough information on the Label level. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
I guess to me it's much better to have one hack in GtkWindow globally (GtkWindow is already a giant special case) than to leak the hack into all widgets that actually do h-for-w. Just a separation of concerns thing. It doesn't make sense for N child widgets inside a window to all be trying to heuristically guess how to make the window have a nice aspect ratio. Just do that on the toplevel. Even if the GtkWindow hack is really nasty like a binary search, that's fine. (I think a binary search might be overkill... picking a default size assuming there's a roughly linear relation between min W x H-for-min-W and nat W x H-for-nat-W probably works fine and is only 3 request cycles and only to pick default size, not on every resize) Then when implementing widgets, just return min size = min useful, natural size = max useful, that is the raw data for GtkWindow, no guesses. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom wrote: > On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote: >> On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote: >> > Agreed, GtkLabel needs to report min size = true min sane size and >> > natural size = either full width, or "a good width" >> > The full width is more correct imo, maybe we should figure out why >> > that doesn't work well. > > I'm not sure you agree completely here, are you saying that a > wrapping label's minimum width should be the width of the largest word ? > or it should be a true sane minimum size ? My point here was mostly about the natural width. I don't have a lot of opinion about what min sane size is (though in general I think it should be "smallest size that can work at all") > I don't completely agree here either, in many cases that are important > to handle the text displayed in a label is some user input, data loaded > from a database or even some translated text that wont fit normal screen > constraints (same goes for the natural width of a GtkCellRendererText). > > For this reason it is important for the programmer to consider setting > "max-width-chars" on a label that may have overly large text. IMO this should never be necessary unless something is broken. The toplevel should pick a default size that's no larger than maximized (work area) by default, if it can do so while staying above its min size. (This may be an important addition to that "GtkWindow default size = natural size" patch.) Widgets should not have to do a bunch of custom f*ing around logic. They should report min useful size and max useful size, done and done. If that doesn't work, the toolkit is broken. Label trying to second-guess stuff to keep the toplevel aspect ratio correct is just broken. Now, we've just established that due to the WM interaction we may have to be broken at least on X ... ;-) but hopefully the consequences of that limitation can be minimized. In theory we could pretty quickly get a new WM protocol in metacity/gnome-shell to fix it for real, too - if we know what the protocol is, which I don't. The only time I think you should have to do max-width-chars is when you don't want the window to ever default to full screen width (presumably you decide this is just ugly, for example). You shouldn't have to set this to unbreak stuff - for example, you shouldn't have to set it just to keep the window from going off the screen. btw shouldn't max-width-chars be called natural-width-chars? >> I certainly always saw the "good width to wrap to" thing as a workaround >> for GTK+ 1/2 geometry management. But picking a good aspect ratio from >> the toplevel will require a binary search. That might be fine if the >> binary search is done only once when picking a default size for the >> toplevel when first mapping it. > > Not sure where this portion is going, ofcourse setting the default width > of a window to be the natural width of the window should be fine and > doable, using reasonably sized labels and good judgement with > "max-width-chars" this is currently doable. I think a good first cut would be "natural width constrained to work area size" - the WM may already do that constraint anyhow, hopefully. Some windows might be sort of oddly wide compared to their height but they won't go offscreen. Making things a pretty aspect ratio could be done via binary search, but maybe is better done by just letting apps set max-width-chars or otherwise messing with their layout. Doing it by magic picking of a "good wrap width" by default ... eh. Such a weird hack. > One thing I have to add is that constraining the width of the window > to be the natural width of the window is surely not what we want; It > would mean that minimum sizes of labels are then unattainable > completely (in which case, why have a minimum size at all ? the minimum > then becomes the natural for the whole window's content). I don't think anyone was suggesting this Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Mon, Oct 11, 2010 at 3:30 PM, Owen Taylor wrote: > Setting the hints dynamically based on the current width can work, if > we're willing to say "screw wireframe resizing" (wireframe resizing > doesn't completely *not* work, you just have to release and retry > a few times to get to certain sizes.) Uggghhh... so the h-f-w request/allocate stuff needs to be exposed to the WM ;-) I can't even think of a good solution in theory, offhand. I guess having labels pick a "good" width is the best option. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Agreed, GtkLabel needs to report min size = true min sane size and natural size = either full width, or "a good width" The full width is more correct imo, maybe we should figure out why that doesn't work well. A related patch attached, if you fix this you'll quickly want it. Also, you said if doing minimum-height-for-natural-width the window doesn't wrap the label and can't be made narrower. I don't understand that... I would expect the min size of the window is the min height for natural width as you propose, and the min width as returned by get_preferred_width(). So the min width ought to be the true min width? Hmm. The "a good width to wrap to" thing seems like pretty much crack to me. If people want their window to have some sort of pleasing aspect ratio they should just pack the label to limit its width, or set default size on the window, or whatever. Or maybe GtkWindow should constrain the default size to "nice aspect ratio" somehow, solving globally for the window instead of per-label. Havoc From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Mon, 6 Sep 2010 11:18:35 -0400 Subject: [PATCH] Make GtkWindow default to natural size not minimum size Otherwise your ellipsized labels all start out ellipsized, unless you manually gtk_window_set_default_size(). This probably makes it important to clamp the window's default size to the size of the monitor's work area. --- gtk/gtkwindow.c |4 ++-- tests/testgtk.c |1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/gtk/gtkwindow.c b/gtk/gtkwindow.c index 5f75dae..b50a9ab 100644 --- a/gtk/gtkwindow.c +++ b/gtk/gtkwindow.c @@ -5725,9 +5725,9 @@ gtk_window_compute_configure_request_size (GtkWindow *window, if (window->need_default_size) { - gtk_widget_get_child_requisition (widget, &requisition); + gtk_size_request_get_size (GTK_SIZE_REQUEST (widget), NULL, &requisition); - /* Default to requisition */ + /* Default to natural requisition */ *width = requisition.width; *height = requisition.height; diff --git a/tests/testgtk.c b/tests/testgtk.c index cddb7df..8ea1117 100644 --- a/tests/testgtk.c +++ b/tests/testgtk.c @@ -8431,6 +8431,7 @@ create_window_sizing (GtkWidget *widget) gtk_widget_get_screen (widget)); label = gtk_label_new (NULL); gtk_label_set_markup (GTK_LABEL (label), "Window being resized\nBlah blah blah blah\nblah blah blah\nblah blah blah blah blah"); + gtk_label_set_ellipsize (GTK_LABEL (label), PANGO_ELLIPSIZE_END); gtk_container_add (GTK_CONTAINER (target_window), label); gtk_widget_show (label); -- 1.7.0.4 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkGroupBox and layout ideas for Gtk3
Hi, On Sun, Oct 10, 2010 at 4:57 PM, Alexander Larsson wrote: > First of all, what happened to Bug 628902 "Add expand flags to > GtkWidget". It seems to have stalled. This would be very useful. > The latest code is on widget-expand-3 branch, fwiw. todo items are: * magic resizability behavior on GtkWindow * write equivalent of GtkBox patch for Table * remove expand child prop from WrapBox (if we keep wrap box, I guess) * possible "do not propagate" special cases see https://bugzilla.gnome.org/show_bug.cgi?id=628902#c24 I think all of these are trivial 10-minute kind of patches except the first one. I'm not sure when I can tackle that task... may be a while. I got tied up in non-GTK stuff again and for GTK I feel like more urgent would be to get all the non-toplevel non-plug/socket widgets off of GdkWindow (step 1 the "events for no window" thread delete input only windows, step 2 figure out clipping and scrolling delete remaining windows, step 3 profit). I'm not sure magic GtkWindow resizability is required to land the patch. If it's done such that setting geometry or resizability always overrides what the expand propagation would dictate, then it may even be ABI compatible. On the other hand, the GtkWindow changes may not really be that hard. I just haven't looked into it and there are a whole bunch of weird cases GtkWindow handles that would be a pain to test. But it may only take somebody a day or less. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
Hi, On Sun, Oct 10, 2010 at 10:41 AM, Tristan Van Berkom wrote: > I would only expect the expand to be distributed evenly among > children as, thats what GtkBox does ;-) But the whole point of the exercise is to mop up GtkBox cruft... > I'm not sure that having all the children stop expanding > when an expand child is added is any worse than having all > the extra column/row spacing suddenly disappear. The general principle I think is that if a child doesn't say it can benefit from expand, it doesn't make sense to expand it. For example, expanding a button just looks bad. > Maybe a similar spreading option would be useful for the Grid ? > (i.e. decide whether Grid children EXPAND, or line up at the START > or END, or get spread EVEN)... You can use widget halign/valign to do START and END right? Then Grid never gets extra allocation. The only case where Grid needs something "special" is if it does get extra allocation, i.e. it is align=FILL. In that case, if there are expand children, obviously extra allocation should go to them. If there are no expand children, then the two choices are to allocate extra space evenly to the children, OR allocate extra space as spacing between the children. Allocating extra space "around" the children is redundant with setting halign/valign on the grid so I think that is a pointless feature. Allocating extra space evenly to the children I think is redundant with setting expand=true on the children. So the only thing that can't be done already is to allocate extra spacing in between the children. You can then get any of the effects: a) no expand=true children, grid align = FILL: extra allocation becomes spacing between children b) any expand=true children, grid align = FILL: extra allocation goes to the expand=true children only c) no expand=true children, grid align = START | CENTER | END: extra allocation is spacing on one side or both sides of grid If it works like GtkBox, then in case a) you just pretend it is case b) with all children set to expand=true. This means: - there's no way to do a) anymore unless you add some special option - the behavior is illogical (widgets with expand=false expand anyway, until you set one to expand=true then they don't?) The simple obvious thing is: children expand only if they are expand=true. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
Hi, On Sun, Oct 10, 2010 at 6:36 AM, Tristan Van Berkom wrote: > bottom or right size of the Grid. (if the user wants the > grid children not to expand at all, they should only have > to pack the whole grid into another container and say that > the grid does not expand). Or set halign/valign on the grid to something other than FILL right? I would expect that if the grid gets an allocation above its request, that allocation goes first to any expand children, and second just centers everything, or creates extra space evenly distributed around non-expand children, perhaps. Actually expanding the non-expand children seems weird (not least because it means as soon as you add an expand child, all the other children stop expanding when they did before). Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
Hi, On Thu, Oct 7, 2010 at 1:18 PM, Federico Mena Quintero wrote: > However, who writes UIs by hand these days? Doesn't everyone just use > Glade? It's a valid point, but I don't know that Glade is always easiest. I don't think it's a good excuse for making the actual API crappy. (In fact I'd almost think Glade should have its own container widget that's designed to be easy to use in a builder, just as in code it's good to have a container widget that's easy to use in code. Do the same top-down exercise with Glade - what would make a container easy to work with in a UI builder - and design based on that.) > I don't know how many other examples you considered while thinking about > your API, but let's see about those three: I knew these were built into gtk and probably ui files, but I still think they're good examples of reasonably complex layouts that show some of what people want to do. > * Our HIG-beloved sections with indented contents in dialog boxes. > There is no official solution to this, and various apps do different > hacks to achieve them. I was thinking this could be built into Grid, but it's normally done with a frame right? Which seems OK too except that Frame's defaults don't match what's wanted. Possibly needed here is a GtkBin that looks the GNOME HIG way on Linux and a windowsy/mac-y way on other platforms. > If you are making your UIs with Glade, it would help for Glade's > usability to be improved in a similar fashion. We should study what > kinds of tricks people use to rearrange widgets... creating a temporary > window, inserting a container, then cutting&pasting widgets into it to > create a holding space, is pretty cumbersome. Exactly, doing an interaction design of how layout should be done in Glade, then designing a widget just for that... would be awesome. Maybe the easy-to-code widget matches the glade widget, I don't know. Not saying we'd hide the glade widget from code or hide the code widget from glade, just that it might make sense to have a widget optimized for those two cases. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
Hi, On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom wrote: > However I would really appreciate it if a widget's placement > inside a container can still be clearly introspected and defined > with container child properties (in other words I think the widget > should be built with child properties and the 'cursor' be a > convenience API layer of sorts). > I agree with this (and almost mentioned it). I guess what I'd say though is, I think the "gridbuilder" should be the primary/expected API when packing with code, and taking the API design "top down," the child properties have to be designed such that the nice gridbuilder is possible. I wouldn't really do the gridbuilder as a literal separate API ("gtkgridbuilder.h"). I think it would add typing and confusion. I'd say go ahead and make it gtk_grid_add_left(), etc. which would be the first API people go for. And then the "raw" child props API could even be _just_ properties (use gtk_container_add_with_properties etc) or just a couple of low level functions that would be documented as "you probably don't want to use this" One question on gridbuilder is whether it's "persistent." For example, it could be that as I'm doing add_left(), add_row(), etc. that is just setting fixed grid coordinates. And then once the grid is created, I can't use the gridbuilder stuff to modify it. Or, it could be that as I do add_left(), add_row(), etc. that is saving a conceptual list of actions and on each relayout, that conceptual list of actions is converted to a table of cells. I think it's maybe the second thing for two reasons: * you can then use "gridbuilder" API to modify the table later. an API could allow you to "set the cursor" to a particular row and next to a particular widget, then you start "gridbuilding" * you need to autocompute table size, so when doing add_left, add_row, etc. you don't know the actual cell coordinates yet It isn't totally clear to me what the right child properties are. Kind of the way I'd approach this would be to have some sample layouts that were typical and Should Be Easy(tm), write nice, logical, non-redundant code that should produce those layouts, then figure out how to implement the widget to support said nice code. Hmm. One other goal ideally achievable, is that a simple one-row box should not have a ton of CPU or memory overhead. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
Oh, another thing to have is probably h-spacing and v-spacing for the grid-wide space between rows and columns. For per-column or per-row spacing you could use a margin or a spacer widget placed on that row (?) If not clear the idea of the exercise I was doing is to figure out how you'd naturally describe a layout, say to another person, in logical terms and without redundancy. So examples of things I think you would not do if talking to a person or just thinking logically include: * doing the pack_end widgets backward * positioning widgets using grid coordinates One litmus test for "too much redundancy" is if you have to change two lines to add or remove a widget. I think to put another widget on a row or to add another row, you should be able to add one line of code without changing other lines, at least in the typical case. Similarly to remove a widget or row, you should just delete the corresponding line of code. GtkTable requires you to change both the table constructor (overall table size) and _then_ possibly re-number a bunch of the other children, so it epic fails this litmus test. Another idea, the "cursor" thing could be done explicitly: GtkGridCursor cursor; gtk_grid_cursor_init(grid, &cursor, row=0); gtk_grid_add_row(grid, &cursor, child); But it seems like extra typing for not much good reason. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
I think a picture would be helpful ;-) Are we sure this is of general interest? It seems like something only a few percent of apps would end up using. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
Hi, Oh, I see now it's a WrapBox replacement I guess (reading threads out of order) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: paint clock
Hi, Maybe the very very simple first step that punts on all the hard stuff is to do a queue-redraw virtualization like this: http://git.clutter-project.org/clutter/commit/?id=961aac3fb36f73d4a48720d93b8928a3e24b5b84 The default implementation of this in GtkWidget would invalidate on GdkWindow, but something like clutter gtk could override and ignore GdkWindow entirely and use a paint clock. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: paint clock
Hi, On Sat, Oct 2, 2010 at 7:32 PM, Soeren Sandmann wrote: > FWIW, I put up the notes I wrote about this subject here: > > http://www.daimi.au.dk/~sandmann/framehandlers.txt > > They were written with a different toolkit than GTK+ in mind, so they > make various assumptions that don't apply to GTK+. For example the > widgets are assumed to not do anything like gdk_window_process_exposes(). > Very interesting! We've messed with various things smarter than what I described for litl shell. Right now it's "do stuff for up to 5ms only if there's anything to do; then paint immediately." This gets throttled by the vsync. We never install a timeout or sleep as long as we have a paint queued. We had terrible luck with anything that involved installing a timeout (i.e. polling with nonzero timeout). In part this may be that the shipping litl product is based on 2008 or so Linux which I believe has 10ms resolution on poll timeouts... so the noise in timeouts is already half a frame. This just can't end well. I believe newer kernels have high-resolution timeouts though... all I know on this subject is from http://lwn.net/Articles/296578/ I think another issue here was that frames are just not that uniform. Some frames have a bunch of crap that happens to happen, like incoming IO, some have none; or some frames might have to upload a texture or something and then the next 10 frames don't have to do that. It isn't very predictable. litl shell is a number of different apps plus a compositing/window manager all crammed into a single process so it may have had more trouble than most things. In short we haven't managed to dynamically pick the 5ms number. But just setting it to 5ms seems to work pretty well. Another number that we've tried to get clever with but failed is the frame timestamp used for tweening. You have this correct in your document of course. The thing that's tempting is to use actual wall clock time. But it seems to be true that animations are prettier if you just add the frame length to it every time, and if the result gets "too far" (for us, 1 frame) behind the wall clock, skip ahead by whole frame intervals thus dropping frames. I guess the reason is that vsync is always going to show the stuff at exact frame intervals, so using any frame timestamp not on those intervals is just wrong. Anyway this is one reason why GtkImage animations and the "traditional JavaScript technique with Date.now()" described in roc's mozRequestAnimationFrame post are inherently not smooth looking. The lag between generating the frame and getting it on the screen is enough to make wall clock time when generating almost irrelevant. I kinda think "snap wall clock time to multiples of frame_length for tweening" will look pretty good even if the app has no awareness of when the vsyncs actually happen, as long as the refresh rate is known you have a good chance that each of your frames will show up and that you'll get a different frame on each vsync. For example even in a non-GL GTK, if GTK queried the refresh rate (e.g. XRRConfigCurrentRate()) and used that for the paint clock, I bet it makes GTK animations look way nicer than they do now. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: paint clock
Hi, On Sat, Oct 2, 2010 at 8:57 PM, Matthias Clasen wrote: > If we move to a fixed order of doing things each frame, like Owen > described here: > http://blog.fishsoup.net/2009/05/28/frames-not-idles/ A link I obviously should have included, thank you >, then the paint > clock could perhaps just have those before/after hooks as signals (as > you already have for paint). If we make animation, input handling and > relayouting a fixed part of the frame cycle, then it is not really a > 'paint' clock anymore. Right. Well I was thinking relayout and update-tweens could maybe be done just by connecting to the before-paint signal in the GdkPaintClock. But maybe it's better to have specific signals for relayout and update animations. Among other things that would put them in a deterministic sequence. (and relayout definitely has to be last) Maybe "master" clock or "frame" clock would be better names. I don't think "paint" is wrong (it _is_ all driven off of repainting, tying everything else to repaint is the point) but clearest name I don't know. Also I hadn't really thought about special-casing X event processing, even though it's the obvious thing to do since Clutter does it, litl shell does it, and Owen discusses it. litl shell also takes a crack at the motion event stuff (though we do it by always using motion hint mask and then doing QueryPointer on each frame if we got a motion, rather than by discarding all but latest event per frame). We just discard the QueryPointer reply, though perhaps it would be better to use it to synthesize a motion event if no actual motion event appeared for the frame. One issue is what to do about "other" stuff (not X events, not resizing, not tweening animations, and not painting) litl shell runs the other stuff for at least 1 mainloop iteration per frame, plus more iterations until we've spent 5ms. 1 iteration per frame of course means all highest (usually default) priority stuff is guaranteed to dispatch once, so one event or one message or one read() off an incoming fd or whatever, per source. Clutter runs the master clock mainloop source as a high idle, so I believe they would allow any default-priority stuff to starve repaint, but would never run idles during an animation. litl shell is happy to run an idle within the 5ms window, but will stop running default-priority stuff (more than one iteration anyway) if we exceed 5ms. Not sure the details matter that much here as long as you have enough performance headroom to be pretty reliably hitting your target framerate. GDK's current repaint handler is a high idle also, same idea as Clutter I guess. GDK then has X events at normal priority so it is always dispatching all events prior to any repainting. Looks like gdbus and gio's GSimpleAsyncResult use default priority, so loading files or talking to other apps are by default treated as equivalent to X events. It's possible these things should really be at idle priority, but it sort of depends on the use-case. I kind of like the idea of limiting "doing stuff" to a fixed time window before we force a repaint. Having the paint clock main loop source use a "popping priority" where it does g_source_set_priority on itself on the fly may actually work I think - gmain.c doesn't seem to say you can't do that. ;-) I don't really like the idea of starving non-painting (even idles) completely just because there's some cheesy animation somewhere in the frame. Just doesn't seem probable anyone ever wants this. I also don't really like the idea of starving repainting completely just because there's a bunch of IO or IPC going on. So in short to me the priority system doesn't seem expressive enough unless something dynamically changes its priority. What's wanted is that we give other stuff priority for "a few ms" and then we force painting to be top priority. It seems like current GDK and Clutter imply that very little should ever use default priority, because delaying repaint for more than a few ms is just fundamentally not OK in most GUI apps. And even if your default-priority thing is relatively fast, at some point in a big app you have N default-priority things, and the paint loop has no ability to limit how many times it dispatches the default priority stuff. (With GMainLoop there's no way at all to avoid dispatching all-or-nothing at a given priority, but at least if you have 30 default-priority things, you can dispatch the 30 only once instead of however long it takes for all 30 to be unready. I think even better might be to be able to dispatch one GSource at a time and then break out of dispatch, but who knows what wild implications that has.) As a practical matter, of course, a GSource dispatch is free to take 100ms to do its thing, and so we're doing cooperative multitasking here; and if performance just fundamentally isn't keeping up, then things get hosed no matter how scheduling is done. But it'd be nice to avoid "accidental total catastrophe." We had a bug in litl s
Re: paint clock
Hi, On Sat, Oct 2, 2010 at 6:37 PM, Xavier Bestel wrote: > * how do you handle multimonitor setups where an application can have 2 > different vblanks to care about ? > Separate paint clock per toplevel, I guess. The approach in the patch of gdk_window_set_paint_clock() would support that. It sort of requires a nonblocking buffer swap though I would think. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK3 breakage
Hi, 2010/9/26 Javier Jardón : > > It returns a pointer to a GObject now > Shouldn't it just return a GtkAdjustment* ? returning GtkObject was some weird legacy thing. Also, isn't gtkobject still there in master? http://git.gnome.org/browse/gtk+/tree/gtk/gtkobject.h Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
A couple other ideas, just to put more options in the pile. Minor concern. gdk_event_set_coords() and set_source() could be problematic in that GdkEvent would become a mutable non-GObject. This is normally considered Bad language-binding-wise. Though in this case, the implications are perhaps limited since events don't "stick around" and multiple proxies for one event would probably be OK. Another API for getting events to no-window widgets, would drop GdkEvent for this, and add something like: /* pretend these are opaque objects with accessors but that's too much typing in this email ;-) */ typedef struct { gdouble x, y; /* widget relative */ GtkWidget *source; GdkDevice *device; /* rest of any useful fields here */ GdkEvent *event; /* original event in case you need window or root relative, or whatever */ } GtkButtonPress; struct GtkEventReceiverClass { void (* button_press) (GtkEventReceiver*, GtkButtonPress*); /* this bubbles the button press. */ } There could or could not be a "base class" for GtkButtonPress, KeyPress, etc. and a "base signal" ::bubble that was emitted for all of them. It could be that each button_press, button_release, etc. bubbles separately with its own vfunc directly. Without the base class, you never actually have to name this GtkEvent or use the word event, which avoids some of the namespace collision. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
Hi, On Wed, Sep 22, 2010 at 10:28 AM, Matthias Clasen wrote: > > Isn't that handled by containers simply not calling draw on covered up > or hidden children ? > yeah, quite possibly. Especially if we move animations into a magic master clock that would also be stopped. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
Hi, On Wed, Sep 22, 2010 at 8:55 AM, Paul Davis wrote: > > i think you might want to consider MAP and UNMAP I was thinking the vfuncs (already called on no-window) and map/unmap signals would be fine. i.e. I agree map is interesting for no-window, but I don't think ::map-event adds anything over just ::map, does it? > (and possibly > VISIBILITY_NOTIFY too) as being in section A2. i know that as they > stand, these refer to GdkWindows, but by implication they also apply > to widgets within the window. Some kind of "are we covered up and do we need to paint" flag could be interesting > in addition, is it really true that drag events are of interest only > in the context of GdkWindow or GdkDisplay? It looks to me like drag events are all handled globally in gtkmain.c, gtkdnd.c and end up converted to signals on GtkWidget (events are not sent to GtkWidget right now). I didn't look super closely though. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
events for no-window widgets
Hi, I've been exploring how widgets with no GdkWindow could receive events. Here are some notes so far in case people have thoughts. Event Types === Events separate very cleanly into "weird lowlevel stuff only matters for GdkWindow" and "things widgets in general including no-window widgets care about" A. Events all widgets care about have two subdivisions: A1. events that bubble: GDK_MOTION_NOTIFY, GDK_BUTTON_PRESS, GDK_2BUTTON_PRESS, GDK_3BUTTON_PRESS, GDK_BUTTON_RELEASE, GDK_SCROLL, GDK_KEY_PRESS, GDK_KEY_RELEASE A2. events that are glorified property notifies: GDK_ENTER_NOTIFY, GDK_LEAVE_NOTIFY, GDK_FOCUS_CHANGE B. Freaky events of interest only in context of GdkWindow or GdkDisplay: GDK_DELETE, GDK_DESTROY, GDK_EXPOSE, GDK_CONFIGURE, GDK_MAP, GDK_UNMAP, GDK_PROPERTY_NOTIFY, GDK_SELECTION_CLEAR, GDK_SELECTION_REQUEST, GDK_SELECTION_NOTIFY, GDK_PROXIMITY_IN, GDK_PROXIMITY_OUT, GDK_DRAG_ENTER, GDK_DRAG_LEAVE, GDK_DRAG_MOTION, GDK_DRAG_STATUS, GDK_DROP_START, GDK_DROP_FINISHED, GDK_CLIENT_EVENT, GDK_VISIBILITY_NOTIFY, GDK_NO_EXPOSE, GDK_WINDOW_STATE, GDK_SETTING, GDK_OWNER_CHANGE, GDK_GRAB_BROKEN, GDK_DAMAGE Unfortunately, the current ::event signal (and per-event-type sub-signals) dump all this together. These are logically very distinct and ideally if we were starting from scratch, I would probably want to see: A1. a "GtkEvent" with some of the obscure lowlevel fields removed, no ->window field, add ->widget field, coords are widget-relative A2. just use property notifies on "contains-pointer" and "has-focus" properties B. GdkEvent as it is now (well, cleaned up, but similar idea) Splitting out B (Window Owners) === A challenge is to think about all code related to B as conceptually a new type, GtkWindowOwner or something. The only instances of this type would be GtkWindow, GtkPlug, GtkSocket, and maybe a couple other "weird" widgets like GL area. Unfortunately this type is sort of a mixin; if it were an abstract base class, then widgets could not be both a GtkWindowOwner and a GtkContainer. This probably means that the WindowOwner functionality has to remain in GtkWidget. Stuff that belongs to the conceptual window owner type could include: the signals for all the B events; event mask; set_window; set_double_buffered; GdkVisual; style_attach(); shape mask. I don't think this stuff can easily be actually split out of GtkWidget. However, I do think it's helpful to think of it as distinct. _Possibly_ it would be clearer to add an interface that explicitly had all this, and make GtkWidget implement that interface, and deprecate the old gtk_widget_ names someday. Or maybe there's a nice solution involving delegation, where window widgets have a helper object and there's a base class for that. Enter/Leave Notify === Here is how I think enter/leave should work: http://bugzilla.clutter-project.org/show_bug.cgi?id=1576 Though I'm not sure events are required at all. Currently, something like GtkButton needs the input-only window just to prelight. I think a simple boolean property "button or any child of button contains pointer" would be sufficient for this, however. Multiple GdkDevice pointers complicates that a bit, though it doesn't look like GtkButton handles that right now. The boolean could be defined to mean that greater-than-zero devices are inside the widget and that would probably work fine for prelighting, better than the current enter/leave events in fact. My current thought here is to have a boolean prop which is set on the leaf widget containing each device and all ancestors of that widget. For convenience, maybe a vfunc or vfunc pair which is invoked whenever this property changes. notify::contains-pointer would already be a signal for it but that's sort of annoying in subclasses. I guess this flag would simply mean "prelight" and that might be handy for the new theme stuff. Given the property, the event would be only on conceptual GtkWindowOwner. No-window widgets would use the property not the event. Implementing "contains-pointer" for no-window widgets would require some kind of pick() virtual method for identifying the widget under the pointer, GtkWidget default implementation just looks at widget allocations, GtkContainer default recurses into its children. Picking would start at the window widget receiving a GdkWindow native motion notify or enter/leave and then generate synthetic events for no-window widgets inside that GdkWindow. Focus Change === I believe the existing has-focus pretty much handles this; similar to the above-proposed notify::contains-pointer, it might be handy to have a virtual function to go with it, or virtual function pair. The fields in the focus change event are only of interest for GtkWindowOwner not for widgets in general, it looks like. Given the property, the event would be only on conceptual GtkWindowOwner. No-window widgets would use the property not the event. Bubble Events === If we solve "A2" enter/leave/focus events with properties, "
Re: rendering-cleanup-next
Hi, On Thu, Sep 16, 2010 at 6:36 AM, Andrew Cowie wrote: > On Sun, 2010-09-12 at 11:23 -0400, Matthias Clasen wrote: > >> > Anyhow, sure, if GTK has no policy that's fine. I assumed it had a >> > sensible policy... >> >> We don't have a written-down policy, beyond 'fit in locally'. But I >> have become increasingly annoyed by trailing whitespace ... > > Can we maybe just use indent? > I think mangling all git blame and history is too radical a move, unless the diff from indent was fairly small. I've needed the blame history several times just in doing a few gtk patches over the last couple weeks (I had to figure out why scrolledwindow needed to look at aux_info for example which went back to 1999 or 2000). No more _new_ broken whitespace is a good goal to start... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
+ g_return_if_fail (GTK_WIDGET_ALLOC_NEEDED (widget)); g_return_if_fail( ! GTK_WIDGET_ALLOC_NEEDED (widget)); right? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte wrote: > On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen > wrote: >> What about the expose_event / gtk_widget_send_expose_event stuff ? Do >> we want to merge what you have first and figure that out afterwards ? >> > I want to figure that out afterwards. It's something I haven't figured > out completely yet. I consider it a part of rendering-cleanup part 4: > The hackfest menace. > The thing about this is someone will have to go git-digging to get back the deleted docs and stuff. We end up intermediately deleting expose-event then bringing it back then moving it to WidgetWithWindow thingy. I can do it after you merge if you like rather than trying to explain what I mean in email. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte wrote: > I'm actually not sure about that. First, we don't have any code that > defines if an allocation is valid or even defines what a "valid" > allocation is. Or do we? gtk_widget_get_allocation() at least doesn't > do anything there. yes, we have GTK_WIDGET_ALLOC_NEEDED(). draw() should whine if an alloc is needed. I don't think there's much question here. Drawing without an updated allocation is just a bug, plain and simple. Widgets need this guarantee. For example if I'm coding GtkLabel, I should be able to create the PangoLayout in size_allocate and assume that I have the right layout in draw(). If you don't require updating the allocation, I might draw() some old text that has been changed. (Not saying GtkLabel works this way, I didn't look, just that if it did work this way it would be correct and would have worked in GTK 2.x. And it's certainly easier to write a correct widget if we keep this invariant.) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Mon, Sep 13, 2010 at 4:26 AM, Alexander Larsson wrote: > I'm personally a tiny bit uneasy about dropping bg None, as in some > cases its really required to do flicker-free stuff in X. However, with a > modern Gtk+ these situations are quite rare, and I don't think any of > these changes really cause any flicker, since: > > 1) In practice almost all non-toplevel GdkWindows in a typical Gtk+ app > are client-side (i.e. have no corresponding native window). This means > that mapping them does not make X clear the area to the background, and > there is no flicker. > > 2) Even for windows with native windows there is often no flicker, as > the X11 gdk backend aggressively set+unsets background None around > things like moves, resizes, maps and reparents in order to not render > anything to the screen until we do the expose. Fair enough. It looked to me like the None still in GTK were all on scrollable areas (text and tree view, GtkLayout). So if those are just client-side anyway, None background isn't doing anything. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
Hi, On Mon, Sep 13, 2010 at 7:06 AM, Tristan Van Berkom wrote: > Heh, do you mean GtkWindow widgets or GtkWidgets that have their own > GdkWindow ? Widgets that have their own GdkWindow i.e. I was proposing that when adjusting a size request, if (gtk_widget_get_window(widget)) { if (*minimum_size < 1) *minimum_size = 1 } > I think essentially to allow 0x0 allocations we either need to > allow GdkWindows to be created at a 0x0 size (currently they > also force >= 1x1 internally)... or we need to add some special casing > code to GtkWidget's to handle their GdkWindows with care at > allocation time (naturally they all just call gdk_window_move_resize() > unconditionally). If you force the 1x1 request then in theory you would not ever get a 0x0 allocation, right? But to be sure could also force 1x1 allocation (which is already done), but change that requirement to only apply if gtk_widget_get_window() != NULL I was proposing this approach - window widgets must be 1x1 - because the alternative is to unmap when receiving a 0x0 allocation. (HippoCanvas does the unmap thing, in fact 0x0 allocation and unmapped are the same state in HippoCanvas, iirc.) I think the unmap-on-0x0 will be complicated to apply to GTK and maybe not that useful, since the goal is to get rid of window widgets, keeping only the ones that truly conceptually have a GdkWindow - toplevels and embeds - and requiring toplevels to be 1x1 is actually logical. Anyway the basic idea is to avoid changing anything too much, just move the arbitrary 1x1 requirement only to those widgets that really need it (those that have a GdkWindow) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Mon, Sep 13, 2010 at 12:05 AM, John Ralls wrote: >> Could also make it a gdk_x11 api. >> But maybe a hint that is a no-op on other backends is better. > > I'm in favor of keeping platform-specific stuff in platform-specific files > and directories, but that's in large part just because I'm a bit compulsive > when it comes to code organization. > Making it gdk_x11 doesn't keep the platform-specific in platform-specific files. It would make all files touched by d3802ca8331ab09fe752407577b12d1525b5d89e now include gdkx.h and an #ifdef'd call to the gdk_x11 API. So textview, layout, treeview, viewport would all now have x11-specific code. The API need not be X specific, though the details depend on how Windows and Mac work and I don't know them. /** * gdk_window_set_clears_background: * @window: a #GdkWindow * @value: #TRUE to clear window to its background when damage occurs * * If a window is set to clear its background, when a region of the window needs repainting because the underlying window system has * discarded the window's pixels, the window system will first clear the region to the window background * (see gdk_window_set_background_pattern()) and then GDK will send a #GdkEventExpose indicating the need to repaint. * * If a window is not set to clear its background, the #GdkEventExpose will be sent but no extra work will be done by the * window system to update the window's pixels. The first change in pixels will come from the expose event handler. * * Clearing the background may produce a superior visual effect in some cases, because the window background may be a more appealing * or less confusing thing to show the user than potentially undefined pixels or leftover framebuffer contents. However, in other contexts, * painting the background creates flicker because the background has little to do with the final window contents, and it's better * to leave whatever is onscreen until the actual window contents can be painted. * * For expose events generated internally to GDK with gdk_window_invalidate_region(), the background will never be cleared. * This is because the purpose of the background clearing is to show the background in the time between window system * losing the pixels, and the application repainting. For application-generated invalidations, the window system is not throwing * away any pixels so there is no issue. * * gdk_window_begin_paint_region() always paints the background, and GTK+ always uses gdk_window_begin_paint_region() * around expose event handlers. * As a result, expose event handlers can assume the background has been painted, even if the window is set not to * clear its background. * * On window systems that retain window contents, there is no need to generate expose events in the window system and * thus gdk_window_set_clears_background() would not do anything. * * On window systems that do not support clearing to background, or do not support clearing to the particular kind of * background pattern you've set, the background will not be cleared. As long as you paint using gdk_window_begin_paint_region() * the final result of your repaint will still be correct, however. */ Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, I merged the main patch to master. I wrote docs (see attached) but did not push them yet because I can't figure out how to actually document a non-signal virtual function in a non-interface. What I have here puts the text of the docs in the HTML but it doesn't look nice. Does gtk-doc just not do this? Havoc From 218ab01aa87e9344f6708ae32d74503014508905 Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Sun, 12 Sep 2010 21:43:39 -0400 Subject: [PATCH] Add documentation on adjust_size_request adjust_size_allocation Also note in the docs for various other functions, whether they use adjusted or "parent container" size allocation. --- gtk/gtksizerequest.c | 59 ++ gtk/gtkwidget.c | 28 ++- gtk/gtkwidget.h | 36 ++ 3 files changed, 121 insertions(+), 2 deletions(-) diff --git a/gtk/gtksizerequest.c b/gtk/gtksizerequest.c index 543bbc1..8ae2662 100644 --- a/gtk/gtksizerequest.c +++ b/gtk/gtksizerequest.c @@ -87,6 +87,34 @@ * width. By following this rule any widget that handles height-for-width * or width-for-height requests will always be allocated at least * enough space to fit its own content. + * + * Often a widget needs to get its own request during size request or + * allocation, for example when computing height it may need to also + * compute width, or when deciding how to use an allocation the widget may + * need to know its natural size. In these cases, the widget should be + * careful to call its virtual methods directly, like this: + * + * Widget calling its own size request method. + * + * GTK_SIZE_REQUEST_GET_IFACE(widget)->get_width(GTK_SIZE_REQUEST(widget), &min, &natural); + * + * + * + * It will not work to use the wrapper functions, such as + * gtk_size_request_get_width(), inside your own size request + * implementation. These return a request adjusted by #GtkSizeGroup + * and by the GtkWidgetClass::adjust_size_request virtual method. If a + * widget used the wrappers inside its virtual method implementations, + * then the adjustments (such as widget margins) would be applied + * twice. GTK+ therefore does not allow this and will warn if you try + * to do it. + * + * Of course if you are getting the size request for + * another widget, such as a child of a + * container, you must use the wrapper APIs; + * otherwise, you would not properly consider widget margins, + * #GtkSizeGroup, and so forth. + * * * */ @@ -423,6 +451,12 @@ gtk_size_request_get_request_mode (GtkSizeRequest *widget) * This call is specific to height-for-width * requests. * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget itself. + * * Since: 3.0 */ void @@ -445,6 +479,13 @@ gtk_size_request_get_width (GtkSizeRequest *widget, * * This call is specific to width-for-height requests. * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget itself. + * + * * Since: 3.0 */ void @@ -468,6 +509,12 @@ gtk_size_request_get_height (GtkSizeRequest *widget, * Retrieves a widget's minimum and natural width if it would be given * the specified @height. * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget itself. + * * Since: 3.0 */ void @@ -490,6 +537,12 @@ gtk_size_request_get_width_for_height (GtkSizeRequest *widget, * Retrieves a widget's minimum and natural height if it would be given * the specified @width. * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget itself. + * * Since: 3.0 */ void @@ -514,6 +567,12 @@ gtk_size_request_get_height_for_width (GtkSizeRequest *widget, * This is used to retrieve a suitable size by container widgets which do * not impose any restrictions on the child placement. * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget i
Re: rendering-cleanup-next
Hi, On Sun, Sep 12, 2010 at 5:05 PM, Matthias Clasen wrote: > Also, the idea to separate the translation and the size in > size_allocate is intriguing. > A prior art thing I thought of that's relevant, Clutter has the translation transform *and* the allocation origin. The clutter model is that there's a transform (a full matrix, 3D of course not 2D as in Cairo) which only affects painting (first you do layout, then you can transform when painting so the actor need not paint inside its allocation). I guess the allocation.x,y translation is conceptually part of the allocation (or part of layout). The thing is that the x,y is only of interest to the parent layout container, while the width,height is also of interest to the child. With adjust_size_allocation, though, child-interesting allocation doesn't really match what the parent assigned anyhow. So gtk_widget_size_allocate() (assigning allocation) could take raw allocation including x,y and then the virtual method (going to child) gets adjusted allocation with no x,y perhaps. The x,y could be handled with no virtualization i.e. just stored by GtkWidget rather than storing it in the size_allocate default handler. Widget implementations could never look at GtkAllocation, only at get_allocated_width/height (whatever that would be called). Container implementations would look at GtkAllocation of their children though. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, I pushed a widget-padding-2 branch which has everything cleaned up. Both widget-padding and widget-padding-2 can be deleted once this is merged. (I can merge if you like or feel free. or let me know what else to change.) While messing with branches, I noticed hp-patches and havoc-patches branches last changed in 2000. I think it's fair to assume I'm not using these anymore and delete them. :-P Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Sun, Sep 12, 2010 at 6:44 AM, Benjamin Otte wrote: > Uh, you've found out about one of my secret projects. Actually, what > I'm aiming at is reftests (see > http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html for > a description). They are independant of font settings, themes etc if > done right. Sounds cool! > A big problem with comparing a rendering to a default image - unless Yeah, agreed that an automated test where canonical images were checked into git would probably keep breaking in annoying ways. I do think it'd be easier than Cairo - or at least, certain tests would be pretty robust. For example, if you packed various colored rectangles into GtkHBox with different packing parameters, I don't think that would have changed its pixels in years - it's not quite like Cairo where you're doing the complex antialiasing and so forth, and the exact pixels rendered aren't necessarily defined. If I have an event box with background color 0xff and I set its size request and pack it into a GtkBox, then that just can't change unless a GTK API has changed. Possibly some font - or fake font that's just full of boxes - could be shipped with GTK to keep text rendering stuff from interfering. However the automated tests are done, just having a "toolset" for rendering out a bunch of useful widget images as PNGs will be awfully handy. Some use-cases: * smoke-test a patch. if I mess with GDK or cairo or size requesting, if I could build and render a set of "before" images on my machine locally, and also a set of "after" images, and quickly do an automated diff - there's no "pixman changed" or "font changed" issues since it's all on my machine, no canonical images located in git - I could see if I triggered any g_warning() or changed how anything paints, without having to manually walk through gtk-demo/testgtk and look for broken stuff, which is what I've been doing * quick-check a theme. sort of like metacity-theme-viewer which shows windows in a bunch of states * write git-bisect scripts. for example it probably would have been worthwhile to automate bisecting that bug we just bisected, by writing a little "git bisect run" program to render the good and bad insensitive label. Anyway however it works, clearly your draw() work is going to enable it, and this has got to be a giant win from that work. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
Hi, On Sun, Sep 12, 2010 at 1:33 AM, Tristan Van Berkom wrote: > Ok I see, so we end up with: > - set_size_request() Can be used to increase the minimum request I was thinking this should stay backward compatible and allow lowering it, fwiw. Though I can't actually come up with a use case, I'm just being paranoid. btw - have you looked into allowing 0x0 allocations at all? (at 0x0, draw() would not be called, I think, so draw() implementations would not have to handle 0x0; also, 0x0 would not really work on window widgets, but this could be addressed by forcing window widgets to have at least a 1x1 minimum size. i.e. replace 1x1 min allocation with a 1x1 min request for window widgets only) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
Hi, On Sun, Sep 12, 2010 at 12:45 AM, Tristan Van Berkom wrote: > While on this topic, there's this XXX comment I left dangling > in gtksizegroup.c: > http://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n677 > > I was thinking maybe that for all the widgets in a group to be > effectively the same size, maybe we should be basing the minimum > base requests from the natural requests of all widgets in a group. I would expect that GtkSizeGroup caused all widgets in the group to request a min size of the largest min size in the group, and a natural size of the largest natural size in the group. Then it Just Works, right? Is there a reason that only one of min or natural can be picked for size group? > But if set_size_request() were to limit the natural size; combining > it with sizegroups that demand/require the natural size as a minimum > might work nicely. To be clear, I was proposing a set_natural_size() or something (i.e. I think making set_size_request set natural would be too incompatible) It might be clearer to rename set_size_request to set_minimum_size() but that function is maybe too heavily used to rename... at least without keeping the old name also. btw along these lines, I can't remember if I filed the attached patch. Natural size much less useful without it. Havoc From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Mon, 6 Sep 2010 11:18:35 -0400 Subject: [PATCH] Make GtkWindow default to natural size not minimum size Otherwise your ellipsized labels all start out ellipsized, unless you manually gtk_window_set_default_size(). This probably makes it important to clamp the window's default size to the size of the monitor's work area. --- gtk/gtkwindow.c |4 ++-- tests/testgtk.c |1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/gtk/gtkwindow.c b/gtk/gtkwindow.c index 5f75dae..b50a9ab 100644 --- a/gtk/gtkwindow.c +++ b/gtk/gtkwindow.c @@ -5725,9 +5725,9 @@ gtk_window_compute_configure_request_size (GtkWindow *window, if (window->need_default_size) { - gtk_widget_get_child_requisition (widget, &requisition); + gtk_size_request_get_size (GTK_SIZE_REQUEST (widget), NULL, &requisition); - /* Default to requisition */ + /* Default to natural requisition */ *width = requisition.width; *height = requisition.height; diff --git a/tests/testgtk.c b/tests/testgtk.c index cddb7df..8ea1117 100644 --- a/tests/testgtk.c +++ b/tests/testgtk.c @@ -8431,6 +8431,7 @@ create_window_sizing (GtkWidget *widget) gtk_widget_get_screen (widget)); label = gtk_label_new (NULL); gtk_label_set_markup (GTK_LABEL (label), "Window being resized\nBlah blah blah blah\nblah blah blah\nblah blah blah blah blah"); + gtk_label_set_ellipsize (GTK_LABEL (label), PANGO_ELLIPSIZE_END); gtk_container_add (GTK_CONTAINER (target_window), label); gtk_widget_show (label); -- 1.7.0.4 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Something that occurred to me mid-bisect is that with Benjamin's draw() work, it would probably be straightforward to write the following test program: * instantiate every widget type in GTK (or even various modes of every widget type, like different text styles, wrap or not, padding/border or not, etc.) * dump a giant directory of PNGs representing the paint of every one of those in every GtkStateType This is already useful because it can be manually inspected and used for example to verify that a theme engine works. But then a natural extension is that you could write a "PNG cmp" tool (load two PNG, compare pixels). Then dump widget renders before, dump widget renders after, compare. If you could control for environmental issues (fonts, font settings) you could have an automated test that 1) ensured the allocate/draw codepath didn't crash or spew debug spam for any widget in GTK (use G_DEBUG=fatal_warnings), and 2) got upset if anything changed about how widgets are rendered. If you changed rendering on purpose, you'd just regen the canonical images. You could even easily test layout algorithms (just render various box packings). And automate testing of widget properties by having handy routines that set every possible enum value of a prop, for example, rendering them all. Seems like a really simple way to get _huge_ test coverage. I guess it was possible already by starting an Xvfb (which you'd have to do anyhow) and taking screenshots... but that might have been slow and/or racy, I don't know. Well, a project for a rainy day. It would have caught this little buglet ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Sat, Sep 11, 2010 at 11:41 PM, Matthias Clasen wrote: > Turns out this is unrelated to your branch. I've bisected this to > Oops, I just burnt a hole in my lap bisecting this too. At least _one_ of those checkouts could have managed not to rebuild the whole tree... I got to this commit though, one after yours, as the guilty one (for me ccacd3a was OK) commit 709e05cdb20fd6d2360b7158286d6c3176c300c0 Author: Benjamin Otte Date: Sat Aug 7 02:18:06 2010 +0200 style: Use _gtk_pango_fill_layout() Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, I pushed the changes I had in mind to the widget-padding branch. I have a rebased/squashed branch cleaned up for merging, too, if anyone wants me to push or send that version. the changes are: 733991c84df4300ec54af8b557385759a93360f0 Rename GtkWidget padding to margin 83008588e162b78f8f66ba371c3691a2ca759f3b Use gint16 for GtkBorder cbfbe68eca5835f8b0151ca77f01ab8b370c50d8 Adapt to widget->allocation becoming private dd3f8cefeb386a34b170b200705dc482435efa84 Just use GtkBorder for padding in GtkAuxInfo If I forgot something we talked about let me know. Otherwise I think this could be merged to master or given a final review. I guess a pending task is to use gtk_container_class_handle_border_width() more, and/or add a GtkMisc equivalent, but not sure we need to block on that. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
Hi, Just thinking, in the new GtkSizeRequest world it's probably more useful to set natural size than minimum size. With Clutter, what we often find ourselves wanting to do at litl is "set natural size, clamping it to be larger than minimum size" So for example setting natural size to 0 would mean "set natural size equal to minimum size" Setting natural width to 100 would be "100, or as small as possible without breaking the widget" This would provide the "set a size manually, but don't break the widget" functionality. Anyhow: it would be a shame to ship the "ignore set size request smaller than min size" by accident. Should I open a bug? Or should I change (and document) set_size_request to "increase only"? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Sat, Sep 11, 2010 at 11:46 AM, Havoc Pennington wrote: > * size_allocate vfunc and wrapper change to (* size_allocate) > (GtkWidget, int w, int h) > Another possible addition here, which is in both Clutter and HippoCanvas, would be an ORIGIN_CHANGED flag. (Clutter uses a flags arg, Hippo uses just a boolean.) One purpose of this flag is that window widgets need to know when the absolute origin changes. This allows them to keep the window positioned properly. You would need this to remove knowledge of windows from the GtkWidget/GtkContainer/GtkSizeRequest/GtkSizeGroup "core" and confine such knowledge to certain GtkWidgetWithWindow classes that had to keep the GdkWindow positioned themselves. (While right now the GTK core takes care of that.) A related cleanup would be to make the widget translation always be with respect to the parent container, rather than with respect to the nearest GdkWindow. At that point you could traverse widgets for most purposes without caring whether they had a window. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Sat, Sep 11, 2010 at 12:57 PM, Benjamin Otte wrote: > Ugh, I'd always assume that widget.get_width() would give me the width > of the widget, not the width the widget thought would be ideal but had > nothing to do with reality. Also, a width getter would never return 2 > values for me. > Should we maybe rename it to gtk_size_request_get_natural/minimum_width()? > Tristan? You really want a single method to do natural and minimum, or else it's really annoying for implementors (the methods share too much code). If going this road, maybe go for consistency with Clutter: call it get_preferred_width(). In earlier GTK patches it was get_desired_width(). May as well match Clutter though right? The problem with having a get_width() that returns allocation is that widgets don't have to have an allocation. Either they've never been allocated at all, or it's out of date. In both those cases, the request is closer to reality. I guess that's why Clutter's get_width() returns allocation if updated and request otherwise ;-) btw if there's a get_allocated_width() (or whatever it's called), it'd be nice to put in: if (widget needs allocation) { g_warning("get_allocated_width() called on a widget that has not yet been allocated. Widgets are only guaranteed to be allocated inside draw() or if you have just allocated them yourself."); } Also, the gtk_widget_draw() wrapper could usefully have: if (widget needs allocation) g_warning("widget must have up-to-date allocation in order to draw it"); Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Sat, Sep 11, 2010 at 1:50 PM, Benjamin Otte wrote: > The problem here is that I want to get rid of proxying the ugly X11 > background API via GDK. Neither Windows nor Quartz have anything > similar. So my approach was to use a cairo_pattern_t in the API and > then say "The backends are responsible for mapping it to the system > backgrounds as well as possible." as we overpaint it during exposes > anyway. So hat we do in the gdk_x11_window_set_background() call is > open for debate. Does GDK have enough information to know when to set background to None? The patch d3802ca Remove calls that try to set GDK_NO_BG basically removes hints to GDK that the background should not be repainted by the OS. I don't know how GDK would know this. I don't know exactly what the API should be. Maybe set_hint_no_clear() or set_autopaint() or whatever it is. The main thing is, I think pre- this patch, things probably did not flicker as much, and post- this patch, they are probably flickery and uglier. So that's a user-visible regression. It just doesn't seem like a good idea to me to regress that. The API for this may be something that's a no-op on Windows and/or Mac, I don't know. I don't really know the right API, but regressing the user-visible would suck, that's the .02 here. I would have to dig into more details to say "here is exactly what would look uglier and how" but I'm just assuming the existing "set background to None" calls had some purpose. > First of all, expose events are already different from all other > events today in GTK2. One of them is sent via > gtk_widget_send_expose(), the other via gtk_widget_send_event(). But send_expose() was only required because no-window widgets get exposes ... but with your patch they no longer need to. In GTK 1.2, iirc, expose-event was the raw GdkWindow event and there was a draw() signal. In 2.0, we consolidated on expose-event and generated expose-event for no-window widgets. With 3.0 and your patch, what would make sense to me is to make expose-event again be just the raw window system event, and no-window widgets therefore never get expose-event. send_expose() would not be needed because expose-event would have zero pre-processing; the pre-processing would all be in front of draw(), not in front of expose-event. expose-event becomes just the raw thing from GdkWindow. Back to the future! > Also, I do think that having two events (draw and expose-event) on > GtkWidget is confusing, in particular because one of them is only > emitted sometimes (gtk_container_propagate_draw() would not cause > expose events). To be clear, I'm talking about making expose-event show up in _less_ of the code. I would say, expose-event should be defined to be exactly what comes from GdkWindow, no pre-processing or special handling _at all_, and it only happens on window widgets. In the GTK of the future, this expose-event thing would be like the other obscure list of events that only window widgets ever get (destroy-notify, visibility-notify, blah blah). These events should all be lifted up out of GtkWidget somehow and only be present on windowed widgets; maybe via an interface, I don't know. A subset of events that are actually of interest to no-window widgets would then need to go to all widgets - motion events, a few others. Possibly the actual event struct even differs. What would be super-clean would be that all dealing with GdkWindow events (and GdkWindow in general) lives walled off in a GtkWidgetWithWindow class. GtkWidget itself should not have any such knowledge. Anyhow so where I'm coming from on this, is that it then makes sense to start moving all the event handling stuff into GtkWidget, in the event-handling methods. But taking events out of the GtkWidget API, and taking them out of code that applies generically to all widgets in gtkmain.c etc. This is all in preparation for then taking most of the event vfuncs and signals and copying them out of GtkWidget and into some sort of GtkWidgetWithWindow. Specifically looking at the patch, first the code in http://git.gnome.org/browse/gtk+/tree/gtk/gtkmain.c?h=rendering-cleanup-next#n1674 i.e. GDK_EXPOSE switch case in gtkmain.c, this could just be in GtkWidget (to be later lifted into the GtkWidgetWithWindow thing). Then looking at gtk_widget_send_expose(), http://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?h=rendering-cleanup-next#n4863 I think this should not ever work on no-window widgets at all; no-window widgets can't get an expose, because expose-event is a GdkWindow thing. So given that it doesn't work on no-window widgets, make it the expose-event default handler. And then when the expose-event vfunc and signal are lifted up and out into GtkWidgetWithWindow, this thing comes with it. Why not just delete gtk_widget_send_expose(). No reason for GTK 3 to have that function I don't think. > What I want to have is a GdkWindow::event signal instead of the magic > gdk_window_set_user_data() function. Then
Re: rendering-cleanup-next
Hi, On Sat, Sep 11, 2010 at 1:11 PM, Benjamin Otte wrote: > This is actually a rather ugly situation right now: Everything in the > widget but the draw function (key press events etc) uses coordinates > relative to the GdkWindow, only the draw function doesn't. So when > calling internal get_offsets() style APIs, the draw function always > has to subtract the allocation again. > Oh I see, got it. Seems like the same basic issue as size_allocate taking the x,y. The big picture goal would be to make widgets always use self-relative coordinates. If there were a facility to get events without having a GdkWindow, it ought to be designed to go ahead and translate the stuff in the events relative to the widget. I had a proposal for that here btw: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00223.html Anyway, certainly ought to land the new rendering branch first. It's so tantalizingly within reach to have the clipping, scrolling, event-getting without windows, plus "all coords are widget-relative" though. Hoping it makes 3.0! Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Sat, Sep 11, 2010 at 12:57 PM, Benjamin Otte wrote: > gtk_paint_*() does - at least in my branch - draw relative to the > passed in cairo_t. As almost all the paint functions take > x,y,width,height anyway it doesn't really matter where the origin of > the cairo_t is. You'll notice in all the "Port to draw vfunc" patches > that I removed allocation.x/y from the x/y parameters. > The original paint functions that took a GdkWindow were > window-relative so had to take into account allocation.x/y. I'm looking at gtk_scale_draw for example on your branch http://git.gnome.org/browse/gtk+/tree/gtk/gtkscale.c?h=rendering-cleanup-next#n1159 Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Sat, Sep 11, 2010 at 12:15 PM, Benjamin Otte wrote: > What's you opinion on having gtk_widget_get_width() and > gtk_widget_get_height() functions? They would just return > widget->priv->allocation.width/height for now. > > Such functions would address your issues and would make writing draw > functions pretty much as simple as they are now, without having to > pass width and height. And in particular, they'd get rid of the need > to think about allocations. > Or would that be a too prominent API? > Yep, I was thinking/assuming there would be exactly this. The only thing I'd add, I think they ought to be named something with "allocated" in there, for a couple reasons: - in many languages GtkSizeRequest::get_width() is already just callable as widget.get_width() - plain get_width() more naturally gets request, anyhow Clutter has a hack where get_width() returns the allocation if valid else the request, but this was a back compat hack / an attempt to be nice to naive users who don't want to think about request vs. allocation. The obvious API might be: get_allocated_width(), get_allocated_height(), get_allocated_size(); or even change get_allocation() to return width,height and add separate get_translation(). Something I just noticed, it looks like widgets are doing get_allocation and looking at allocation.x,y still because gtk_paint_* seems to assume that the cairo_t is not translated? I guess the natural new way for this to work would be for gtk_paint to pass the theme engine a cairo_t already translated and clipped to the box the theme element is supposed to be inside. Maybe the new theme branch has something more radical though. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Sat, Sep 11, 2010 at 11:16 AM, Havoc Pennington wrote: > I still think passing width, height to draw() is weird. btw, I guess the argument here (per IRC) is that people might be confused by allocation.x,y. But this is a really weak band-aid fix for that, which will be wrong in the long term. The solution to allocation x,y is to set the larger goal: widgets don't know their transform (currently GTK only supports translation transforms, of course). Widgets should always work in a self-relative coordinate system, on the rare weird occasion where they don't, they can use gtk_widget_translate_coordinates() which eventually could even support rotation and scaling, or there could be a flavor that gives you a matrix. The actual bug is that widget_size_allocate() receives an x,y and gtk_widget_get_allocation() gets an x,y. That's where the bug should be fixed, not by adding some confusing stuff to draw(). It would take some thought to fix the leakage of x,y on the allocation side, but I think that thought is what's needed, rather than band-aid pseudo-solutions in draw(). Roughly, the solution could be that: * size_allocate vfunc and wrapper change to (* size_allocate) (GtkWidget, int w, int h) * add gtk_widget_set_translation(widget,x,y)/get_translation() * containers now have to call gtk_widget_allocate_and_translate(widget, rectangle) convenience function instead of size_allocate(). This convenience function obviously calls size_allocate(rect.w, rect.h) and set_translation(rect.x, rect.y) This is a pretty breaking change, but porting apps is no harder than changing expose-event to draw. If you want to then be really sick and twisted, once you clear out GdkWindow you can support a full cairo_matrix_t instead of just translation... which would be logical and straightforward now that you've kicked the translation out of the allocation. Another possible solution is to keep the width,height to draw(), but _get rid of size allocate_; widgets would then be supposed to support any width,height at any time being passed to draw(), and they'd in practice always have to cache their last layout for performance, most likely. (they'd sort of make the first part of draw() do what they do now in size_allocate(), iff the allocation has changed, and cache the result). I don't think this is a very nice solution because it makes draw() methods multi-purpose and clunky. I think it's cleaner to have separate vfuncs for doing the layout and handling a paint on the layout, as GTK already has. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Awesome! Some stuff I noticed looking through the branch: * A round of rebase/squash might be nice which would make it easier to review, for example c5c08bafb94e794a88ef5d650999f46b419429ed could squish into 9badb81a7ed62af1cdf11eb31c7e94293a683429 (I was pretty confused by the None there at first) * I'm skeptical of removing ability to set window background to None. This feature can be important to avoid visual artifacts on X11. The API should maybe change to not involve a "NULL" pixmap; conceptually, what this means is "window system should not auto-clear or auto-paint the background on exposes" - I don't know if any other platform has the concept. A new API could be gdk_window_set_paint_background(gboolean) rather than set_pixmap(NULL) I think d3802ca "Remove calls that try to set GDK_NO_BG on their windows" probably results in some things being more ugly. (flashing/flicker) This almost goes away as an issue if dropping all subwindows, but I think setting None on toplevels will still be important sometimes. I guess in future-composited-desktop-world this also fades in importance but I'm not sure on when/whether/details. Anyway - the commit message "undefined behavior is not a good idea" seems like you're missing the point of this - the idea is not to leave the window bg undefined, it's to wait and let the app repaint it, instead of first having window system repaint then the app repaints (which inherently flickers). * I think it would be nicer than send_expose, if you kept expose_event, but had gtk_widget_real_expose_event() do the GDK_EXPOSE case from gtk_main_do_event() and then also have the code in send_expose(). i.e. the default handler for expose_event should set things up and call draw(). It seems to me kind of bizarre to treat expose events differently from the others. Right now all GdkWindow events are on Widget. I would think what makes sense is to keep them all there, until widget->window becomes optional, and then move them all to some sort of GtkWidgetWithWindow iface where widgets that subscribe to a GdkWindow's events would get these but not widgets in general. The way you have it here, there's no way for people to customize the raw event handling. Say for example I'm doing a GL-based widget, or who knows what other weird thing, maybe my app uses Skia, maybe I want to get the raw expose event. If that makes sense for the app and I don't need draw-to-pdf, I should be able to do it. Maybe I have a legacy app that has a pile of Xlib drawing code. An alternative, which I think is hackier, would be to make gtk_cairo_get_event() public. Anyway the ultimate goal would be for only toplevel GtkWindow plus wonky widgets (GL, embeds) to have the event signals. But whichever widgets keep the event signals, should still have the expose signal, imo. * I still think passing width, height to draw() is weird. If I were just reading this API, I would *strongly* tend to guess that it was the damage rectangle or else the size I'm supposed to paint to, but it isn't. It's a redundant copy of allocation size. Plus, you're clipping to allocation _anyway_ so in most cases I don't even _need_ the allocation size. So the width/height here are just _extra_ typing, not saving me typing allocation.width,height. App developers basically _should_ ignore these. So why are they here? These parameters just confuse and raise questions. If they are defined to be allocation.width,height, they should not exist. App devs are going to think "OK, it can't be that" and think it has to be damage region, or think they are supposed to support drawing to an arbitrary size, or otherwise try to rationalize the existence of these pointless redundant parameters. But they don't have a rationale ;-) Things with no point are confusing. Gratuitous cognitive load. If I need to know the allocation, then I'll look at the allocation. * There's a fair bit of trailing whitespace in the patch. Maybe turn on trailing-whitespace-highlighting in your editor. * Shouldn't gtk_widget_is_drawable() just die? It seems to me the draw() method can be called when not mapped or visible. In fact it can be useful to do that if you're trying to render offscreen or to pdf. (Maybe we want to pedantically require visible, but I don't think we should have to be mapped, which implies in a toplevel window system window.) gtk_widget_draw() is documented as requiring the widget to be drawable, but I don't see why draw() in its current form needs widgets to be mapped. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK team meeting - 2010-09-07
Hi, On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi wrote: > - branches for alignment and margin for review widget-padding and widget-expand branches pushed, widget-expand includes widget-padding Pending changes not in the branches yet include: - rename padding to margin - some docs tweaks Matthias mentioned - patch all layout containers to handle expand - patch GtkWindow to auto-set resizability If you build the branches you can run tests/testadjustsize and tests/testexpand Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK team meeting - 2010-09-07
Hi, On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi wrote: > - possible addition pre-3.0: surface ↔ pixbuf conversion functions in gdk > Incidentally, these should probably be in gdk-pixbuf (to avoid cairo dep they could just go to guint8*). The main use I guess is say in Clutter or other cairo-but-not-GdkDrawable contexts. btw, I think the patch on https://bugzilla.gnome.org/show_bug.cgi?id=491507 provides the proper API that we'd also want if cairo adds support for "classic pixbuf" format. The patch on the bug is having to keep a surface for cairo format, and a manual byte buffer for old pixbuf format. But if cairo had old pixbuf format, you'd just keep a surface, period, done. Either way I think you want new_from_cairo_surface(), get_cairo_surface(), and you want to do the deprecations of get_pixels(), GdkColorspace, and related stuff. I'd say a great path would be to put in the patch on 491507 - possibly in "max compatibility" mode, i.e. always keep the pixel buffer around and just pay the memory cost - and then when new cairo comes out, you could 100% compatibly drop the pixel buffer and have *only* a cairo surface representation. If cairo does not add classic pixbuf format (I'm still not sure it should), then things are trickier, because with my patch on 491507 you have to choose between definitely 100% compatible but uses 2x memory until all apps stop calling get_pixels() and new_with_data() and new(), or 98% compatible but avoids 2x memory sooner. Still, assuming a cairo dependency is OK, I think the API (and the deprecations) in this patch are right. The implementation depends a bit on how picky we want to be about breaking apps in super obscure cases, and what cairo ends up doing. If a cairo dependency is not ok, then just simple convert-to-from-guint8-in-cairo-format is one option, or my original patch, http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00022.html, is a kind of middle ground between "just add a very raw pixel convert function" and "swap internal pixbuf representation to cairo" - some advantages of that original patch include: - no cairo dependency - Loader could then grow a property for the desired format, and apps could opt in to load in cairo format - if/when a cairo dep was added and cairo had "classic pixbuf" format, pixbuf could be transparently switched to keep a cairo surface internally The disadvantages vs. the patch attached to https://bugzilla.gnome.org/show_bug.cgi?id=491507 might include: - does not automatically convert any existing pixbufs without changing apps - does not cache a cairo surface on each pixbuf, gdk continues to convert on each paint - does not deprecate get_pixels() (since there's no cairo surface to use instead) - can't draw to the pixbuf with cairo (until cairo supports pixbuf format) Overall I think adding new_from_cairo_surface(), get_cairo_surface(), and deprecating get_pixels/new_from_data/&friends, is the right thing to do, whether or not cairo gets classic pixbuf format. And the patch is pretty much ready. (and tunable for desired compatibility vs. efficiency tradeoff) But I do understand if people don't have time to dig in for 3.0. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
Hi, On Tue, Sep 7, 2010 at 3:49 AM, Tristan Van Berkom wrote: > What is the use-case for forcing a widget to request something smaller > than it's content ? > I think the use-cases are mostly caused by the old limited layout system. For example, to get a label to ellipsize, you used to have to set its size request to something small and then pack it with expand=true. I'd say the semantics of set_size_request should be "pretend the widget's size request vfuncs returned what set_size_request set" so size groups and widget padding would still potentially grow that size request. It is just a back compat API though really; I'm not sure what it's really good for. The "only increase what vfuncs return" behavior does seem more useful in at least one case, where you just want to be sure the min size is at least something-or-other, but are willing to use a larger value if the true min size is larger. I guess some searching through apps to see how they use it might be instructive. (Is there an easy way to search through code for lots of gtk apps?) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Cool. So I'm inclined to search-and-replace the patch and make the properties: margin-left margin-right margin-top margin-bottom margin /* sets all four at once */ I'll give it a couple more days though in case this turns out to be controversial so I don't do too much busywork ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_container_new_child (was Re: Wrapping Box Container)
I forgot that GtkWidget::parent already works: g_object_new (TYPE_FOO, "parent", box, "blah", 42, NULL) This is a pretty nice solution I think. You don't even have to save a pointer to the new object if you aren't doing anything other than adding it to parent and setting a couple of props. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: magic expand flag on GtkWidget
Hi, On Mon, Sep 6, 2010 at 8:18 PM, Matthias Clasen wrote: > In particular the automatic window resizability will be nice. Unfortunately this part is scary ;-) a whole lot of the gtkwindow.c code related to this was last touched by me in 2001, some was last touched even earlier than that, and I remember having to revise my rewrite of this code many many times to handle all the corner cases. But maybe this feature is relatively superficial and won't interact with the scary stuff, right? ... But yeah, this is kind of the cool part. At the same time we can fix gtkwindow to take advantage of natural size to set default size, and I think in order to do that, we need to constrain the default size to the monitor work area. > I do foresee some complications in the expand-propagation for more > complicated containers, though: > > - Just because a tab label expands, the notebook should probably not. > > - a table/grid can only expand vertically if it has an entire row of > vertically expanding children (I think ?) > Right. I think the containers should be able to fix this stuff in their compute_expand. Also, for similar cases an app may have, they can set an explicit expand=FALSE on a container and expansion will not propagate upward any further. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
legacy-free grid container
With https://bugzilla.gnome.org/show_bug.cgi?id=628828 and https://bugzilla.gnome.org/show_bug.cgi?id=628902 Box and Table are pretty much all messed-up. They have a bunch of redundant flags to specify, and their redundant fill flag is a problem because it has the wrong default (must always be true to make the widget flags work). Rather than churn up Box and Table in-place, maybe it would be nicer to create a legacy-free new GtkGrid. The basic idea of GtkGrid is: * it just puts things in rows and columns, and implements homogeneity; expand, fill, padding are now all in Widget * it is an infinite grid, not a fixed size at construct time like GtkTable. so you don't have to keep construct size in sync with what you add. It auto-resizes to hold stuff. * the coordinate system goes into negative numbers, so you can add things on either side of the axes * its "default" mode if you just container_add() is like a box, in that it just keeps appending children to the axis. they are then in a single-row or column table. this lets it replace Box. * but you can also do an add_at(grid, child, x, y, cells_wide, cells_high) (note, coords then WxH in cells, rather than annoying "attach points" where you have to change both numbers to move) * you could also do add_by(grid, existing_child, child, side_of_existing_child, cells_wide, cells_high) which lets you build things up relatively. this is nice because if you want a stack of stuff above the foobar, and you insert something before the foobar, you don't have to go and redo all your coordinates * have separate "h" and "v" homogeneous flags to force all rows or all columns to be the same height * have separate "h" and "v" spacing which would be the same between all rows or all columns * minor thing: kill SHRINK mode in table, it's broken (esp. in a world with min size separate from natural) * an issue: the naming of the cell-based access (x,y) is a mess if you allow it to be GtkOrientable like box. but if you require an add_on_axis(orientation, child) then it's not as convenient as box. Anyway something like that. It's just a box if you create and container_add(), but it can become a table if you just start packing things off the main axis (no more "box regret" - "I wish I'd used a table now that I'm halfway into this!"). And it lacks the redundant padding, expand, fill confusion when mixed with the new patches. Probably there are better plans but that's the one I thought of. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
magic expand flag on GtkWidget
Hi, This is a major enough change it should probably hit the list and not just bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=628902 The patch needs finishing as noted in the bug but you can already play with it, it just is missing some production details. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
combo/option (was Re: [REMINDER] GTK+ Team Meeting, 2010-09-07)
Hi, On Mon, Sep 6, 2010 at 10:06 AM, Emmanuele Bassi wrote: >> ‣ undo combobox / option menu mix ? what is the argument on this? sounds like going in circles ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
https://bugzilla.gnome.org/show_bug.cgi?id=628828 has a patch ready for review. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
Bugzilla is down, so here's a patch for another problem Havoc From d8b6eb473b0eb13b9540f91516f2f60df2d5f1a7 Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Sun, 5 Sep 2010 01:42:14 -0400 Subject: [PATCH] default impls of width_for_height,hfw should chain directly not use wrapper API In GtkBin and GtkWidget we tried to provide handy defaults that call get_width if there's no get_width_for_height and get_height for get_height_for_width. However, they used the wrapper API on GtkSizeRequest instead of chaining directly to the other method implementation. This could result in all kinds of surprising behavior, for example, get_width_for_height() would now already include the effects of set_size_request(). If nothing else it's inefficient. But it's just conceptually wrong, because to chain to another implementation, we should call the other implementation, not call a wrapper around the other implementation (when we're already inside a previous invocation of the wrapper, i.e. compute_size_for_orientation() ends up reinvoking itself in the same orientation on the same object which it pretty likely isn't intending to do) --- gtk/gtkbin.c| 11 --- gtk/gtkwidget.c |6 +++--- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/gtk/gtkbin.c b/gtk/gtkbin.c index ecc2b99..b550009 100644 --- a/gtk/gtkbin.c +++ b/gtk/gtkbin.c @@ -214,10 +214,15 @@ get_child_padding_delta (GtkBin *bin, gint *delta_v) { GtkBinPrivate *priv = bin->priv; - gint hmin, vmin, child_hmin, child_vmin; + gint hmin, vmin, hnat, vnat, child_hmin, child_vmin; - gtk_size_request_get_width (GTK_SIZE_REQUEST (bin), &hmin, NULL); - gtk_size_request_get_height (GTK_SIZE_REQUEST (bin), &vmin, NULL); + /* we can't use gtk_size_request_get_width() wrapper because we want + * our "original" request, not any external adjustments from + * set_size_request() or whatever. we have to ask for natural also + * because NULL isn't allowed for the direct vfuncs + */ + GTK_SIZE_REQUEST_GET_IFACE (bin)->get_width(GTK_SIZE_REQUEST (bin), &hmin, &hnat); + GTK_SIZE_REQUEST_GET_IFACE (bin)->get_height (GTK_SIZE_REQUEST (bin), &vmin, &vnat); gtk_size_request_get_width (GTK_SIZE_REQUEST (priv->child), &child_hmin, NULL); gtk_size_request_get_height (GTK_SIZE_REQUEST (priv->child), &child_vmin, NULL); diff --git a/gtk/gtkwidget.c b/gtk/gtkwidget.c index 20ddbbf..95ad36f 100644 --- a/gtk/gtkwidget.c +++ b/gtk/gtkwidget.c @@ -10927,7 +10927,7 @@ gtk_widget_real_get_height_for_width (GtkSizeRequest *layout, gint *minimum_height, gint *natural_height) { - gtk_size_request_get_height (layout, minimum_height, natural_height); + GTK_SIZE_REQUEST_GET_IFACE (layout)->get_height(layout, minimum_height, natural_height); } static void @@ -10935,8 +10935,8 @@ gtk_widget_real_get_width_for_height (GtkSizeRequest *layout, gint height, gint *minimum_width, gint *natural_width) -{ - gtk_size_request_get_width (layout, minimum_width, natural_width); +{ + GTK_SIZE_REQUEST_GET_IFACE (layout)->get_width(layout, minimum_width, natural_width); } static void -- 1.7.0.4 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions re: aux info, size request
Also, 4. AuxInfo still contains x,y, x_set, y_set and code reads them, but commit 0d322676dcb06be62329a7d4373c497993509fbd removed set_uposition and now there is no way to set these - so they should die, right? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list