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 christ...@lanedo.com 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:17 PM, Morten Welinder mort...@gnome.org 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 sha...@gnome.org 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 Fri, May 13, 2011 at 12:00 PM, Matthias Clasen matthias.cla...@gmail.com 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: align vs expand vs grid
Hi, On Thu, May 12, 2011 at 9:53 PM, Benjamin Otte o...@gnome.org 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: 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 czon...@gmail.com 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 Thu, Feb 24, 2011 at 8:51 PM, Wen-Yen Chuang ca...@calno.com 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: GtkApplication and argc/arv
Hi, On Fri, Feb 25, 2011 at 9:13 PM, Wen-Yen Chuang ca...@calno.com 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: 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: microseconds ought to be enough for anybody
Hi, On Mon, Nov 1, 2010 at 12:06 PM, Ryan Lortie de...@desrt.ca 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: microseconds ought to be enough for anybody
Hi, On Mon, Nov 1, 2010 at 1:06 PM, John Ralls jra...@ceridwen.us 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 2:10 PM, Peter Clifton pc...@cam.ac.uk 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: Can I get a quick overview of GtkApplication actions?
Hi, On Mon, Nov 1, 2010 at 2:25 PM, Matthias Clasen matthias.cla...@gmail.com 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: Doubts about GPeriodic
Hi, On Sat, Oct 23, 2010 at 3:37 PM, Owen Taylor otay...@redhat.com 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. Agree the default should plan for
Re: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 10:24 AM, Owen Taylor otay...@redhat.com 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 until we
Re: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 10:28 AM, David Zeuthen zeut...@gmail.com 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: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 5:06 PM, Paul Davis p...@linuxaudiosystems.com 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 4:48 PM, Owen Taylor otay...@redhat.com 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 the vsync *
Re: Doubts about GPeriodic
Hi, On Fri, Oct 22, 2010 at 9:56 PM, Paul Davis p...@linuxaudiosystems.com 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
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 = time since start of animation - 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: Doubts about GPeriodic
Hi, On Thu, Oct 21, 2010 at 4:26 AM, Emmanuele Bassi eba...@gmail.com 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
Hi, On Thu, Oct 21, 2010 at 5:46 AM, Ryan Lortie de...@desrt.ca 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, 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:47 PM, David Zeuthen zeut...@gmail.com 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: Docs for the gtk-style-context branch changes
Hi, On Tue, Oct 19, 2010 at 7:49 AM, Carlos Garnacho carl...@gnome.org 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,
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
trista...@openismus.com 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 Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom trista...@openismus.com 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, On Fri, Oct 15, 2010 at 8:55 AM, Tristan Van Berkom trista...@openismus.com 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]
Hi, On Fri, Oct 15, 2010 at 9:55 AM, Havoc Pennington h...@pobox.com 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,
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]
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 2:44 AM, Tristan Van Berkom trista...@openismus.com 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
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 11:20 AM, Tristan Van Berkom trista...@openismus.com 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
Hi, On Tue, Oct 12, 2010 at 11:40 AM, Tristan Van Berkom trista...@openismus.com 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 12:09 PM, Owen Taylor otay...@redhat.com 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 12:38 PM, Havoc Pennington h...@pobox.com 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
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 h...@pobox.com
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), span foreground=\purple\bigWindow being resized/big/span\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: Minimum height for minimum width
Hi, On Mon, Oct 11, 2010 at 3:30 PM, Owen Taylor otay...@redhat.com 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: grid widget (was Re: possible removal of GtkWrapBox)
Hi, On Sun, Oct 10, 2010 at 6:36 AM, Tristan Van Berkom trista...@openismus.com 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: GtkGroupBox and layout ideas for Gtk3
Hi, On Sun, Oct 10, 2010 at 4:57 PM, Alexander Larsson al...@redhat.com 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: 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: 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: 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: grid widget (was Re: possible removal of GtkWrapBox)
Hi, On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom trista...@openismus.com 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)
Hi, On Thu, Oct 7, 2010 at 1:18 PM, Federico Mena Quintero feder...@ximian.com 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 cuttingpasting 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: 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: GTK3 breakage
Hi, 2010/9/26 Javier Jardón jjar...@gnome.org: 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
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, A1 remains. I've
Re: events for no-window widgets
Hi, On Wed, Sep 22, 2010 at 8:55 AM, Paul Davis p...@linuxaudiosystems.com 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
Re: events for no-window widgets
Hi, On Wed, Sep 22, 2010 at 10:28 AM, Matthias Clasen matthias.cla...@gmail.com 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: rendering-cleanup-next
Hi, On Thu, Sep 16, 2010 at 6:36 AM, Andrew Cowie and...@operationaldynamics.com 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
Hi, On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte o...@gnome.org 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 Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte o...@gnome.org wrote: On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen matthias.cla...@gmail.com 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
+ 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: questions re: aux info, size request
Hi,
On Mon, Sep 13, 2010 at 7:06 AM, Tristan Van Berkom
trista...@openismus.com 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 4:26 AM, Alexander Larsson al...@redhat.com 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 Sun, Sep 12, 2010 at 1:33 AM, Tristan Van Berkom trista...@openismus.com 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: padding cleanup
Hi, On Sun, Sep 12, 2010 at 6:44 AM, Benjamin Otte o...@gnome.org 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: rendering-cleanup-next
Hi, On Sun, Sep 12, 2010 at 5:05 PM, Matthias Clasen matthias.cla...@gmail.com 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 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 h...@pobox.com 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: + * example + * titleWidget calling its own size request method./title + * programlisting + * GTK_SIZE_REQUEST_GET_IFACE(widget)-gt;get_width(GTK_SIZE_REQUEST(widget), min, natural); + * /programlisting + * /example + * + * 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 + * emphasisanother/emphasis widget, such as a child of a + * container, you emphasismust/emphasis use the wrapper APIs; + * otherwise, you would not properly consider widget margins, + * #GtkSizeGroup, and so forth. + * * /para * /refsect2 */ @@ -423,6 +451,12 @@ gtk_size_request_get_request_mode (GtkSizeRequest *widget) * noteparaThis call is specific to height-for-width * requests./para/note * + * 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, * * noteparaThis call is specific to width-for-height requests./para/note * + * 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
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: rendering-cleanup-next
Hi, On Sat, Sep 11, 2010 at 11:16 AM, Havoc Pennington h...@pobox.com 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
Hi, On Sat, Sep 11, 2010 at 12:15 PM, Benjamin Otte o...@gnome.org 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 12:57 PM, Benjamin Otte o...@gnome.org 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 1:11 PM, Benjamin Otte o...@gnome.org 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 11:46 AM, Havoc Pennington h...@pobox.com 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: padding cleanup
Hi, On Sat, Sep 11, 2010 at 11:41 PM, Matthias Clasen matthias.cla...@gmail.com 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 o...@redhat.com 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: questions re: aux info, size request
Hi,
On Sun, Sep 12, 2010 at 12:45 AM, Tristan Van Berkom
trista...@openismus.com 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 h...@pobox.com
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), span foreground=\purple\bigWindow being resized/big/span\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
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: questions re: aux info, size request
Hi, On Tue, Sep 7, 2010 at 3:49 AM, Tristan Van Berkom trista...@openismus.com 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: Minutes of the GTK team meeting - 2010-09-07
Hi, On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi eba...@gmail.com 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: Minutes of the GTK team meeting - 2010-09-07
Hi, On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi eba...@gmail.com 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
combo/option (was Re: [REMINDER] GTK+ Team Meeting, 2010-09-07)
Hi, On Mon, Sep 6, 2010 at 10:06 AM, Emmanuele Bassi eba...@gmail.com 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
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
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
Re: magic expand flag on GtkWidget
Hi, On Mon, Sep 6, 2010 at 8:18 PM, Matthias Clasen matthias.cla...@gmail.com 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
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: 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 about GTK3
I'd say a useful emphasis is to focus on enabling deprecation by adding the new way, rather than on actually removing the old way. e.g. on my pixbuf patch, the changes allow dropping any actual use of the old format. But going on a compile with GDK_PIXBUF_DISABLE_DEPRECATED spree just in pixbuf and gtk without considering apps, would take for freaking ever and can be done post-3.0. Also making gdk-pixbuf use cairo in most cases internally can be done post-3.0 on the get rid of GdkWindow, there's incremental no-pain-to-apps steps like: - add an API to get events without a window (can still ship GTK here) - add an API to get do clip and scroll without a window (can still ship GTK here) - fix up public APIs that require a window (textview border windows, entry icon window) (can still ship GTK here) - drop input-only windows from no-window widgets that get input (can still ship GTK here) - make more window widgets into no-window widgets, can still ship GTK with 0,1,2,3...N of these fixed - actually remove GdkWindow (too harsh to do in 3.0 ... but it could be marked deprecated ... and in any case all of the above work is still useful even if GTK ships before reaching this) So much that can be done step-by-step while keeping a shippable lib at all times, without ever leaving a pile of parts on the floor, or breaking apps much. On the widget padding path, I think the goal would be to add the padding/alignment to widget; but the old stuff would all still be there, marked deprecated. New variants of box_pack and other methods that take padding/align args could be added. Actually removing GtkMisc, GtkAlignment, and box padding would be too radical without a few years for people to adapt. If there's a bunch of deprecated code and over future release cycles that deprecated stuff starts getting purged from GTK itself and other major libs and apps, then already on many embedded type platforms people can start ripping the deprecated out of their build of GTK, and designing apps that rely on no child windows, things like that. For GNOME itself to clean up disk usage would take a GTK 4.x, but it will arrive someday. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
questions re: aux info, size request
Hi, several questions looking at this code, 1. I may be nuts but I really thought set_size_request() could reduce a size request below the widget's normal request, back in the day. However, won't this code allow set_size_request to *increase* min size only? http://git.gnome.org/browse/gtk+/tree/gtk/gtksizerequest.c#n311 i.e. cached_size-minimum_size = MAX (cached_size-minimum_size, group_size); and cached_size-minimum_size is straight from the widget itself. Am I reading something wrong or was this an intentional change or a bug? 2. The use of AuxInfo in gtkscrolledwindow.c is weird weird weird http://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n1873 scrolledwindow uses the forced size request of the child (done with set_size_request) but does not use the actual size request of the child? what? This appears to be ancient 12-year-old weirdness, see commit 0d15bc66, http://git.gnome.org/browse/gtk+/diff/gtk/gtkscrolledwindow.c?id=0d15bc6687e9a9718273a37b3d880f6526fa91ce In an era of min size, I think we should declare this silly and just use the min size of the child. The commit introducing this seems to be in a world where set_usize() (the old set_size_request name) meant user-explicitly-set size instead of its current meaning of minimum size request 3. The use of AuxInfo in gtklabel.c I don't really understand, plus seems buggy Basically, in a w-for-h h-for-w world, why does label need to look at this itself and include it in its size request up front? I can imagine the motivation back in the days when wrapped labels had to be hacky, but now they should not have to be hacky. What is the story on this? If it is used, the buggy is that it seems to ignore the GtkMisc padding etc. properties and assume that set_size_request only sets the size of the text itself, rather than the entire widget. 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
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
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 h...@pobox.com
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: pixbuf-cairo_surface_t conversion
Hi, On Fri, Sep 3, 2010 at 4:05 AM, Andrew Cowie and...@operationaldynamics.com wrote: We can kiss gdk_pixbuf_get_pixels() goodbye, no problem, but I'm just curious what someone would replace it with... draw to a Cairo image surface, save that to a PNG and then load it and... oh wait. :) The idea is that what you do now is get the cairo surface and then cairo_image_surface_get-data() of course, frequently things that previously required pixel access would now be doable with cairo operations, which can only be a win for language bindings. As usually happens across the language barrier, we had to copy the array anyway, so I'm not really fussed where we get it from. Or, are we advised to tell developers no more access to an image's pixels? No, they just have to access them via the cairo surface Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuflt;-gt;cairo_surface_t conversion
Hi, On Fri, Sep 3, 2010 at 4:17 AM, Benjamin Otte o...@gnome.org wrote: - I'm not sure where to store contents Naïvely, it doesn't make a lot of sense to store images that are only used on the X server in client memory and upload them every time we need them. But then, closing a connection to the X server does invalidate the pixels of an Xlib surface, but not of an image surface. And storing it twice is needless dulicate memory usage. So no idea where to best store pixel data. When GdkPixbuf was invented the sentiment was certainly that storing contents on the server was wrong. I can't rattle reasons offhand. For just icons and things, doing the shared memory copy to the server on paint ought to be cheap, I guess. If you have some giant image, then you have to be more clever (I would assume things like EOG are at least mildly clever, though I don't know) In any case I don't think it really works to make GdkPixbuf able to have any type of cairo surface, because the semantics become too undefined; you might not be able to get at pixels, might not have a fixed size, etc. I think for GdkPixbuf the cairo surface should be defined to be an image surface. This is what I did in the patch. Maybe there's some type of cache facility for image surfaces that are kept on the server for fast paint, I don't know. - Cairo surfaces have no size, and can change it In general, Cairo surfaces have no size. That is why there is no call to cairo_surface_get_size(). (This might change in the future, but hasn't yet.) Image surfaces have a size though - We lose precision if we use Cairo formats Premultiplied formats have less precision then unpremultiplied ones; the conversion from unpremultiplied to premultiplied is not lossless. (0x40FF and 0x40FEFEFE are both stored as 0x40404040 unpremultiplied.) So loading, then saving a PNG might result in a different image being stored. Not sure that is a good idea. I wasn't aware of this and it would break the patch as I have it, presumably. (Or any scheme where we don't always keep the original classic-style pixbuf pixels.) By break I guess I mean some pixels would change from FE to FF by themselves which may not be a bad enough problem to keep around image data in a weird format and keep copying it, especially when we have to convert FE to FF at paint time anyway.) yeah, actually if we're already going FE to FF at paint time then I guess it doesn't matter if we do it earlier when we store the pixels. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hi, On Fri, Sep 3, 2010 at 11:35 AM, Shawn Bakhtiar shashan...@hotmail.com wrote: Sorry this may be a very inept question: How will this effect integration with OpenGL. I know we use a lot of get/sets on pixels buffers; off screen rendering, textured (especial animated) and tricks. You want and need that raw data access. taking it way I think would also break GTKGLExt if I am not mistaken? This pixbuf stuff shouldn't affect opengl (except by possibly eliminating a conversion, since a GL implementation is more likely to support the cairo format than the classic format, I think) Native-requiring widgets like GLExt and XEmbed and whatever will just be special cased in GTK someway and won't draw to a cairo context. This is an issue for Benjamin's rendering cleanup, but not related to pixbufs. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hi, I thought of another approach to this problem. Don't expose the pixbuf format at all; keep it as-is. However, add: gdk_pixbuf_get_cairo_surface() gdk_pixbuf_new_from_cairo_surface(cairo_surface_t *surface); Now, keep the cairo surface internally, strong-ref'd by the pixbuf. The pixbuf would have pixels == NULL. If someone does gdk_pixbuf_get_pixels(), then lazily create the old pixbuf format and keep that copy of the pixels around. Otherwise, never create the old format. If you create a pixbuf NOT from a cairo surface, then the reverse occurs. pixels != NULL, and a surface is lazily created and kept around if anyone does gdk_pixbuf_get_cairo_surface(). There are various APIs in gdk-pixbuf that call get_pixels() in the implementation. These would all be modified to use cairo_surface_t operations instead if the cairo_surface was set, and use the existing pixbuf code otherwise. So basically a GdkPixbuf can be either the old stuff internally, or a cairo surface internally, or have both cached, but with the same API either way. Some downsides: - two copies of the pixels would be kept for the two formats, in the case where we create a pixbuf in old format and then draw it. - APIs that modify the pixels might have to either modify both copies, or discard one of them to be lazily recreated - but wouldn't know which to toss - if you modified the surface pixels or the old-style pixels by hand, it would not affect the other format - this could be VERY surprising. The main upside would be zero new API, other than to/from cairo surface. The downside is that if something dumb is happening that ends up repeatedly converting pixels or keeping both pixel representations around eating memory, it would not necessarily be obvious. In this scheme, perhaps get_pixels, get_n_channels, get_colorspace, etc. (all the internal representation APIs) would be deprecated. You are supposed to port that code to get the surface and then mess with the cairo surface. Conceptually, GdkPixbuf's exposed pixel buffer representation becomes cairo_surface_t instead of colorspace, n_channels, get_pixels, etc.; GdkPixbuf is a cairo_surface_t wrapper instead of a guchar* wrapper. If/when get_pixels can be removed entirely, then the internal representation could always be cairo_surface_t _only_. The old constructors would immediately convert to cairo format. get_pixels() is the only reason external code would ever care about pixbuf internal representation. 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 Thu, Sep 2, 2010 at 6:14 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Of course, this only handles the size_request side of things. It would be up to individual containers to respect the h/v-align in their size_allocate (basically replacing their current child properties), correct ? Couldn't we do it in gtk_widget_size_allocate ? I can just try this patch and any reason it won't work may become clear quickly One thing that is not addressed yet is how we will split this between application control and theme control. To illustrate the point, here is the list of 'layout' properties we have currently: GtkAlignment::bottom-padding GtkAlignment::left-padding GtkAlignment::right-padding GtkAlignment::top-padding GtkContainer::border-width GtkMisc::xalign GtkMisc::yalign GtkMisc::xpad GtkMisc::ypad The above would all be replaced by GtkWidget props I think GtkBox::spacing GtkButtonBox::layout-style GtkTable::column-spacing GtkTable::row-spacing GtkExpander::spacing These would remain as container-specific probably (though I don't really know what Expander::spacing is and didn't look) And here are some of the 'layout' style properties: I think we could add style props on GtkWidget that would modify the padding on the widget (I don't know if they'd just replace the programmer-set padding, or be an adjustment to it?). That would be simple once GtkWidget has padding, I think. I don't know if the widget style props would replace most of these though - it looks like most of these paddings and spacings are somewhere inside a widget, not on the border. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hi, On Thu, Sep 2, 2010 at 11:21 PM, Andrew Cowie and...@operationaldynamics.com wrote: Are you thinking of the loaders populating an image surface (and thus being in application memory) or populating an xlib surface (and thus being in X server memory?) I'm not proposing any change here. Loaders currently go to pixbufs (which are always application memory), and I'm proposing that when a pixbuf uses a cairo surface as representation, that cairo surface is always an image surface. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
Hi, On Wed, Sep 1, 2010 at 6:37 AM, Tristan Van Berkom trista...@openismus.com wrote: SPREAD_EVEN is exactly that.. adding extra space between the children as spacing, and there is SPREAD_EXPAND for the other (not sure if that could be better explained). that's what I was saying, just that the docs could use a small wording tweak. (because distributing extra space between children could mean either among the children - what I read the first few times - or in between them as spacing) What would we prefer here ? A single AttachOptions type which can be used amongst many containers or a custom enumeration ? I think AttachOptions is just broken, personally (though it beats booleans for readability). FILL should be in an enum with start, end, center since it is logically exclusive with those. SHRINK is just broken (widgets should never get less than their min size). So only EXPAND is a valid flag. Obviously the main gist of my comments would be most useful if actually fixing up FILL and padding to be props of widget instead of props of containers. 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 Wed, Sep 1, 2010 at 12:24 PM, Shaun McCance sha...@gnome.org wrote: Would it be better to have padding-start and padding-end, rather than -left and -right, and have it do the right thing in RTL locales? I've often wished CSS did it that way, and GTK+ does do most things with start and end already. Hmm. does GTK usually do that or does it just name them left and right and then flip left and right in RTL? Problem with start and end is it doesn't convey vertical vs. horizontal. I guess you could do hpadding-start hpadding-end. Still isn't the RTL support based on the app developer just thinking LTR and then GTK inverting everything? 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 Wed, Sep 1, 2010 at 2:03 PM, Shaun McCance sha...@gnome.org wrote: Well, all of the packing functions use start and end, but I guess that's just to make the term orientation-neutral. Looking through the docs, I do see properties like left-attach, left-margin, and left-padding. So it doesn't make sense to use start and end unless we switch all terminology. That's probably just pointless API churn. Side note: browsers are starting to provide properties using start and end: http://help.dottoro.com/lcedmdkb.php Well, what does GtkAlignment do already with its padding? I think the question is, does GTK just flip left and right, or does GTK let you choose to force left/right regardless of text direction and then also let you virtualize with start/end. I'd guess the browsers are not comfortable / unable to just flip all lefts and rights so they are adding new props for auto-flipping padding. The problem is if you have something called left or right which does NOT auto-flip, people will use it, and then be broken in RTL. I'd almost be inclined to have foo-left, foo-right which flip and then _if there's a use-case_ foo-left-in-all-text-directions and foo-right-in-all-text-directions which don't flip. But I don't know much about it, honestly. However it works, the obvious, default thing app developers will do probably ought to work by default in RTL. I kind of suspect padding-left and padding-right are the obvious default thing app devs will use. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_container_new_child (was Re: Wrapping Box Container)
Hi, On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington h...@pobox.com wrote: With my proposed padding cleanup though that issue goes away: child = g_object_new(TYPE_MYCHILD, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); insert_child(layout, child, 2, GTK_WRAP_BOX_PACK_Y_EXPAND); Really great would be: gtk_container_add_with_properties(layout, child, position, 2, y-expand, TRUE, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); which would work if we made gtk_container_set() and friends fall back to props on the child if not finding a child prop on the container. Kind of magic, but also really handy and results in very readable code. The patch is kind of a pain because gtkcontainer.c relies on weird gobject internals (seriously, #include gobject/gobjectnotifyqueue.c ?) and stealing part of g_object_set() with public GObject API basically isn't possible. However, either a bit of a hack in here or a quick API addition to libgobject would make this a simple feature to accomplish. EVEN MORE AWESOME would be: child = gtk_container_new_child(layout, MY_TYPE_WHATEVER, position, 2, y-expand, TRUE, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); sweet! even construct-only properties could be set here. 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 Mon, Aug 30, 2010 at 4:22 AM, Steve Frécinaux nudr...@gmail.com wrote: When the said window is not maximized, the scrollbar is often not on the edge of the window, because it can be in a notebook for instance (as it is the case in gedit) or have margins, but when the window is maximized, it needs to be on the edge so one can benefit from Fitt's law for scrolling: moving one's mouse to the far end of the screen and use the wheel. Are you suggesting some sort of automatically collapse padding when on a Fitt's edge feature? Or even better, make the padding clickable in that kind of situation? That would be easier if centralizing padding a bit I guess. Another thing your mail made me realize, by moving padding into widgets such as Button the padding area could become clickable (I guess in some of the implementation schemes I mentioned, the input-only window would probably end up not including padding, but in others it could). I don't know if padding should be clickable - or only clickable if it's between the widget and a Fitt's edge? If adding a nicer, more automatic way for no-window widgets to get events (as part of dropping GdkWindow), one possible elaboration would be to be smart about whether events on padding go to widgets, possibly including a rule that the widget only gets padding events if the padding is against a Fitt's edge. These features all seem like elaborations of padding cleanup but I do think a padding cleanup (and having padding generally be part of clickable widgets, not part of the layout container) would help do a nice Fitt's law feature. 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, Aug 29, 2010 at 7:02 PM, Havoc Pennington h...@pobox.com wrote: 2. supporting superclasses deriving from GtkWidget that want to add more padding area stuff to their subclasses on top of what GtkWidget already does. GtkMisc would be an example - maybe the only example? I forgot about Container::border-width which is another example of this. It might have the same two possible solutions: virtualize add/remove padding (cleaning up subclasses in the process) and make border-width additive with Widget padding, or just make border-width set the new widget padding props. In either case when porting Container subclasses, all border-width knowledge could be deleted from the subclass. border-width of course is yet another redundant padding API that could be deprecated. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Looking at ClutterBoxLayout, they separate x and y fill, which may be
worth adding here.
void clutter_box_layout_pack
(ClutterBoxLayout*layout,
ClutterActor*actor,
gboolean
expand,
gboolean
x_fill,
gboolean
y_fill,
ClutterBoxAlignment x_align,
ClutterBoxAlignment y_align);
This function has the same too many bools and ints problem as
gtk_box_pack_start though (always have to look up the order when
reading/writing code, no compiler warning on mixing them up), and has
fill and align as separate dimensions, so I'd like to fix those issues
with a nice enum.
In my patch this would probably become:
typedef enum
{
GTK_ALIGN_FILL_HORIZONTAL,
GTK_ALIGN_FILL_VERTICAL,
GTK_ALIGN_FILL, /* or FILL_BOTH? */
GTK_ALIGN_START,
GTK_ALIGN_END,
GTK_ALIGN_CENTER
} GtkAlign;
So that would add another nice handy feature that's annoying to do
with GtkBox right now - you could eliminate the need for a
GtkAlignment to keep a widget from expanding perpendicular to box
orientation.
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 Mon, Aug 30, 2010 at 1:26 PM, Behdad Esfahbod beh...@behdad.org wrote: On 08/29/10 19:02, Havoc Pennington wrote: - is it called padding or border (border is nice perhaps since it contrasts with all the existing stuff called padding) Why not copy the CSS box model to the extent that it's relevant? Yeah (that's why I called it padding). I was just thinking it might be less confusing if this was border and all the deprecated stuff was padding. Or I guess this could match CSS and call it border and not include the background. Should probably first decide if whatever-it-is should include the background or not. Well, first decide if we want it at all ;-) 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 Mon, Aug 30, 2010 at 5:00 PM, Behdad Esfahbod beh...@behdad.org wrote: Well, I was implicitly suggesting that we take all of CSS margin, border, padding and then some. I see. Yeah, that could be cool. I thought about it a little but you have to figure out what background and border color mean in a GTK context; is there a way to set them? do widgets paint them or are they auto-painted before widget_draw() is invoked? Are they set by apps or by themes or both? In my sketchy patch the padding is the part inside the widget that has the widget's background, so it does leave room to add border and margin and the result would be CSS-alike. While if you renamed padding to border in this patch you'd be locked in to a non-CSS-like naming. I think it'd be fairly logical to first mop up padding (as in this patch) and then do follow-on patches to add border color (border pattern?), border, and margin. The border and margin patches would need the same add extra space in superclass mechanisms I was talking about here, but they'd also add the need for a paint edges in superclass mechanism of some kind. I guess even padding creates a painting question for any children with a non-transparent background that would logically extend into the padding - are there examples? I haven't looked at the new CSS-like styling mechanism at all so I don't know how that would interact. I do think padding can be cleaned up without having to solve all this (but maybe solving border and margin is pretty easy, I just haven't investigated) Should also seriously think through the use cases for CSS border and margin. Padding is widely used (via the various ways to set it in GTK), but there's no current way to do CSS-like border or margin, and I at least haven't seen people clamoring to be able to make colored borders or add transparent margins outside those colored borders. Of course in a canvas-like/HTML-like completely custom UI, i.e. nonstandard widgets that ignore the theme, it makes more sense. Another possibility is that CSS-like border should be something themes can set, if it'd be useful there. I don't know. it's a lot of additional questions and new use-cases, while padding is more of a cleanup. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
