Re: Modernizing the display loop [try 2]

2011-12-16 Thread Havoc Pennington
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

2011-05-31 Thread Havoc Pennington
Hi,

On Tue, May 31, 2011 at 5:47 AM, Christian Dywan  wrote:
> This is a great argument. There was a mistake. It made you notice the API is 
> inconsistent, so you suddenly insist that GLib can't be improved further 
> without rewriting all the functions

It didn't "make me notice" - I've known about this issue for many
years, including in all the other threads about it. I also wrote the
GError API docs 11 years ago, which explain the issue. You can find
years-old emails with me making the same "duplicate error-throwing API
for bindings" point about libdbus, if you do some googling. This is a
15-year-old issue, or so.

It's a tradeoff. We could redo thousands of functions with duplicate
functions to be used only from language bindings, or we could live
with this design decision. I personally think 15 years of experience
show that we can survive without a major API redo.

I agree that g_warning/critical can be nicer than g_error in a certain
way, fwiw, though when it's up to me I make both abort and consider
them the same.

Anyway, I don't make the decision on this.

 I'm just trying to tell you why it is how it is and just how long
it's been that way. This thread is hardly the first one to suddenly
realize this is how GLib works and get upset about it. But GLib has
always worked this way.

There are other people you'd have to convince if you wanted to change anything.

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


Re: About gsettings aborting on unkown schemas

2011-05-30 Thread Havoc Pennington
Hi,

On Mon, May 30, 2011 at 8:37 PM, Shaun McCance  wrote:
> But I want to point out that my point was never that GLib
> should behave like a language with exceptions. Just that
> it should let bindings in those languages behave like they
> should.

I agree that would be ideal if you were optimizing for non-C.

But the only way to do that is to replicate the entire API currently
lacking an error indicator, with a second _with_error version of every
function.

Some functions may happen to have some other ad hoc way to do an error
(like returning NULL) but it'd just be some subset without rhyme or
reason.

If you aren't prepared to do the _with_error() replication of the API,
then doing it here and there at random is kinda weird. Either it's
needed or not, it isn't needed here and there at random.

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


Re: About gsettings aborting on unkown schemas

2011-05-30 Thread Havoc Pennington
Hi,

On Mon, May 30, 2011 at 8:17 PM, Morten Welinder  wrote:
> Doing a g_return_val_if_fail is fine here.  That will give the user a
> chance of saving his work.  This is in contrast to g_error which is a
> sure way of eating data.

If that's the argument it's fine. I treat return_if_fail and g_error
the same (often setting the env variable to make return_if_fail
crash).

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


Re: About gsettings aborting on unkown schemas

2011-05-27 Thread Havoc Pennington
Hi,

Man, how many times has this thread happened? At least fifty.

On Fri, May 27, 2011 at 10:57 AM, Shaun McCance  wrote:
> try:
>    load_some_extension()
> except:
>    warn("This extension sucks. I'm disabling it and moving on.")
>
> Of course, GLib is C. We don't have exceptions. We have GError,
> which is a decent foundation for exceptions in language bindings.
> But if we don't use it, then languages that could otherwise do
> the right thing are screwed.

This is the core thing. People who expect no g_error/abort are used to
languages with exceptions.

The thing that's different about C is that an "exception" (think
GError) changes the function signature of that function... _and_ *all
callers* in any library or app!

One of the very foundational design decisions of GLib, back in the
90s, was to not have an error code from every single function.
(Contrast with some other utility libraries.) And this decision has
been continued in GTK+ and all the other family of GLib-based
libraries. Some might like to change it, but people, it's too late to
paint this bikeshed another color with thousands and thousands of
existing API calls relying on it. It does, you have to admit, make the
C API a lot nicer.

The core principle that allows most functions to "always succeed" is
that programming bugs are not "thrown," they just terminate the
program.

Config schemas that contain type checking and default values are part
of the program; the program is either incorrect, or redundant in a way
likely to create bugs, without the schemas. If schemas were just docs
or something, it would be a different situation.

If you really want to "handle" this, make it impossible to be missing
the schema, by embedding the schema in the binary at compile time,
perhaps. I don't know.

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


Re: align vs expand vs grid

2011-05-15 Thread Havoc Pennington
Hi,

On Thu, May 12, 2011 at 9:53 PM, Benjamin Otte  wrote:
> Don't assign any extra space to children, use it as space on the
> right/bottom side. (This is the current behavior)

This seems screwy, unless the grid has left/top alignment set. I would
expect the grid to position the children according the alignment set
on the grid (center children as a whole if grid is aligned center,
etc.) - this should Just Work because the grid layout code should not
work with an area exceeding the children's natural size if the grid
isn't set to FILL and the children aren't expanding.

> And I think this principle is wrong. First of all every other
> container (that is not considered for deprecation) does assign extra
> space to children (in particular all subclasses of GtkBin do, such as
> GtkWindow, or GtkExpander).

GtkBin only assigns extra space to children if align=FILL on the bin, right?

This is just an attempt to interpret "scale up the widget content to
fill the area," by passing the buck down to the children of the bin.

> Second, if children should never get
> assigned extra space, why do we have the ALIGN_FILL parameter?

You'd use FILL to say that the child, once expanded, should somehow
grow its content (e.g. by scaling) rather than just centering (or
left/right-aligning) its content by adding blank space.

> Third,
> if the grid decides where to put the extra space, the align property
> does not ever make sense

The align property should determine whether the grid's layout code
even sees extra space. If it isn't FILL, then it should just be
looking at a natural-size-sized area on the start/end/center, I'd
think.

> Fourth, 2 interesting invariants hold for a Grid with one
> child: 1) It behaves identical to all bin subclasses and 2) it does
> not modify the layout at all.

If you set align=center on a Bin then say the frame in GtkFrame should
not fill extra space, it should be centered.

The only difference with GtkGrid I think is that you have an
alternative potential interpretation of FILL, which is to add spacing
amongst children, instead of passing through to children. But I do
think Grid should match Bin in that it shouldn't add space *around*
the children in order to implement FILL.

What I was arguing in
https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00072.html
I guess is that adding spacing is more useful than passing through to
the children, since you can set the children to expand if you want
pass through to children, while adding the spacing is an
otherwise-unavailable feature.

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


Re: align vs expand vs grid

2011-05-15 Thread Havoc Pennington
Hi,

On Fri, May 13, 2011 at 12:00 PM, Matthias Clasen
 wrote:
>> Second, if children should never get
>> assigned extra space, why do we have the ALIGN_FILL parameter?
>
> expand is about whether you _want_ the child to receive extra space.
> align=fill is about how the child should react if it _gets_ extra
> space, wanted or not...
>

I agree with this, that's exactly how I would have answered.

A widget can get extra space without having expand=true, say for
example it's in a container that forces all children to be the same
size.

expand means "extra space is useful" while align describes how to
handle the extra space.

If you think of an image widget, maybe centering the image and scaling
the image up to fill the space would both be useful behaviors,
depending on the app. So you could use align=CENTER or align=FILL.
Something like that.

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


Re: decrease widget show time

2011-03-26 Thread Havoc Pennington
czk, another thing you'll need to do to get useful results is run a
lot of iterations. If you get this all going in a loop then you can
run sysprof for a while to get enough data. I would try to keep
running for 20-30 seconds.

To see one-time startup initialization, your loop will have to keep
relaunching the app (rather than just reshowing the window in a single
process).

Havoc

On Fri, Mar 25, 2011 at 11:35 AM, czk  wrote:
> Thanks, I ever use oprofile, but it didn't help me much. May I to try
> sysprof.
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: GtkApplication and argc/arv

2011-02-26 Thread Havoc Pennington
Hi,

On Sat, Feb 26, 2011 at 9:35 AM, David Zeuthen  wrote:
>  but if someone writes a nice dbus-daemon(1) patch, we
> would probably accept it, right?
>

I suppose... if they had enough test coverage to prove it actually worked ...

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


Re: GtkApplication and argc/arv

2011-02-25 Thread Havoc Pennington
Hi,

On Fri, Feb 25, 2011 at 9:13 PM, Wen-Yen Chuang  wrote:
>
> I suppose GtkApplication users do not need to handle dbus directly.
>
> So if GtkApplication can handle dbus restart / dbus crash, I may also
> consider using GtkApplication for single instance app.

However, the whole restart issue and those debian discussions you
linked to don't really apply to GtkApplication, because it uses the
session rather than the system bus, as far as I know.

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


Re: GtkApplication and argc/arv

2011-02-25 Thread Havoc Pennington
Hi,

On Thu, Feb 24, 2011 at 8:51 PM, Wen-Yen Chuang  wrote:
> a.) restart dbus daemon (and keep everything communicating to dbus
>    still working) is not supported by upstream in a sensible way.
>    [1][2][3][4]

upstream doesn't support this because it isn't a dbus issue. The
problem is that no apps handle restart.

So upstream's advice is, don't restart, because apps won't handle it.

If you want to fix all the apps, you can do so. There are no
dbus-daemon changes required.

(fwiw, g_bus_own_name() in gdbus could in theory make it considerably
easier to handle bus restart, assuming gdbus itself handles it.)

The reason apps don't handle it is because this is a very hard thing
to handle and requires per-app work. You'd have the same problem with
any stateful IPC protocol. (You can build stateless protocols on dbus
if you like, that will have no issue.)

Anyway, the upstream position, or at least my opinion, with respect to
the system bus, is "restarting won't work in practice because you
can't rely on apps handling it" rather than "apps should not handle
it." If apps handle it that's great.

The links you mention are just a bunch of confused people blaming the
protocol, when the issue is the missing logic in apps.

With respect to the session bus, the bus exiting is supposed to end
the session, so in that case exiting has special meaning and apps
should not try to survive it. The same is true of gnome-session for
example.

But still, that is a case of policy decision for what apps do, and has
nothing to do with dbus-daemon or the dbus protocol.

> b.) dbus can not be used over network
>    You have to setup a proxy for dbus to use it over network.

You can enable TCP if you have shared network homedirs and it ought to
work. If you don't have shared homedirs you would have to add support
for another auth method, something that nobody has done yet, but
anyone is certainly welcome. For some applications, you may also be
able to use anonymous auth (i.e. no-auth mode).

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


Re: Shrinking and growing widgets in GTK+ 3.x

2010-12-02 Thread Havoc Pennington
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?

2010-11-05 Thread Havoc Pennington
This document may help you:
http://git.gnome.org/browse/gtk+/tree/docs/text_widget_internals.txt

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


Re: Can I get a quick overview of GtkApplication actions?

2010-11-01 Thread Havoc Pennington
Hi,

On Mon, Nov 1, 2010 at 2:25 PM, Matthias Clasen
 wrote:
>
> In fact, here it is:
> http://library.gnome.org/devel/gio/2.27/GApplication.html#gapplication-example-actions

Was a bit confused reading this example, what are the hold/release in
the action callbacks about? Would they only be needed if someone runs
the main loop in the callback?

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


Re: microseconds ought to be enough for anybody

2010-11-01 Thread Havoc Pennington
Hi,

On Mon, Nov 1, 2010 at 2:10 PM, Peter Clifton  wrote:
>> Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code.
>
> Much as I am a fan of self-documenting code.. isn't "* 1000" much
> shorter and easier?

Well there's already G_USEC_PER_SEC but I guess it's saving typing of
more zeroes.

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


Re: microseconds ought to be enough for anybody

2010-11-01 Thread Havoc Pennington
Hi,

On Mon, Nov 1, 2010 at 1:06 PM, John Ralls  wrote:
> I don't see any reason to have a replacement for GDate.

fwiw, the original (and possibly only) use of GDate was for security
price data (Open/High/Low/Close), which has only a day, not a time or
timezone. This is also why GDate is not opaque, because it was
important to be able to allocate a huge array of GDate quickly.

Not that this makes GDate something that should be in a
general-purpose lib like GLib, but it is a use-case that I'm not sure
GDateTime would cover.

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


Re: microseconds ought to be enough for anybody

2010-11-01 Thread Havoc Pennington
Hi,

On Mon, Nov 1, 2010 at 12:06 PM, Ryan Lortie  wrote:
> The conclusion of all of this is one point: barring substantial
> complaints, the be-all and end-all of time in glib is going to be
> microseconds stored in a gint64.

Your arguments sound right and a nice upgrade over current APIs.

Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code.

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


Re: Doubts about GPeriodic

2010-10-23 Thread Havoc Pennington
Hi,

On Sat, Oct 23, 2010 at 3:37 PM, Owen Taylor  wrote:
>  - We should not start painting the next frame until we are notified
>   the last frame is complete.

Does frame-complete arrive when "we just did the vsync" i.e. last
frame is just now on the screen?

We can dispatch "other stuff" while we wait for this, right? Does the
time between sending off the buffer swap, and getting the frame
complete back, count as time spent doing other stuff? I guess that
would roughly mean "if paint finishes earlier than it had to, get
ahead on other stuff in the meantime" - the wait-for-frame-complete is
a way to take advantage of any time in the 50% designated for painting
that we didn't need.

I mean, presumably while waiting for frame-complete the main loop is
going to run, the question is just whether that time gap factors into
any of the time calculations.

>  paint time    other time      fps   work fraction
>  ==    ==      ===   =
>  1ms           15ms             60   94%
>  8ms            8ms             60   50%
>  10ms          22ms             30   68%
>  17ms          15ms             30   47%
>  20ms          12ms             30   38%
>  24ms           8ms             30   33%
>  40ms          10ms             20   20%
>  55ms          11ms             15   20%
>  90ms          10ms             10   10%
>
> But what this does mean is that there is a cliff across different
> systems here that's even worse than it looks from above. Take a very
> non-extreme example - if I'm testing my app on my laptop, maybe painting
> is taking 20ms, and I'm getting a reasonable 30fps. I give it to someone
> with a netbook where CPU and GPU are half the speed and painting takes
> 40ms. The framerate drops only to 20fps but the time for a background
> operation to finish increases by 3.8x. The netbook user has half the CPU
> and we're using only half that half to do the background work.

Good breakdown, a detail, at some point animations are just unusable.
I think you need a pretty smooth / reliable 15-20fps-ish for an
animation to be even worth doing, really. If you average a rate like
that but have some big hang at the start or end, or if you average a
really bad rate like 5-10fps, my experience is that people say "this
is slow and sucks" and also the animations don't usually achieve the
UI feedback goal because people don't perceive motion, they perceive
an annoying artifact.

I don't know exactly how to deal with that. It doesn't really matter
for the tree view thing, that's not an animation. But I do wonder if
we could automatically make an animation drop all frames, if it's only
going to have 4 frames anyway, or whatever. I guess this is a side
issue / additional elaboration.

> So, there's some appeal to actually base it on measured frame times.
> Using just the last frame time is not a reliable measure, since frame
> painting times (using "painting" to include event process and relayout)
> are very spiky. Something like:

I had awful luck with this. (I did try the averaging over a window of
a few frames. I didn't try minimum.)
It's just really lumpy. Say you're transitioning from one screen to
another, on the first frame maybe you're laying out the new screen and
uploading some textures for it, and then you have potentially very
different repaint times for the original screen alone, both screens at
once during transition, and the final screen. And especially on crappy
hardware, maybe you only get a few frames in the whole animation to
begin with. Minimum might be more stable than average. Another issue
with animation is you don't know the average until you're well into
the animation.

Now in the tree view case, rather than an animation case, I'd expect
very uniform paint times.

Here's a direction of thought: do things differently when there's an
animation active vs. when we're doing a "regular" paint. litl shell
actually does track this. The problem with it (maybe obviously) is if
you have any continuous/persistent animations.

>  - Average time over last three frames
>  - Minimum time over last three frames
>  - Average time over last three frames where only motion events were
>   delivered

I wonder if some kind of synthetic benchmark would end up working more
predictably. Sort of like that "performance score" Windows will
compute for you. Maybe they even store that somewhere and base stuff
on it, who knows.

Though as long as we're only using this for a *max* time to do "other
stuff," rather than setting a timeout or simply blocking, it isn't
exactly the end of the world if we get this wrong.

> Basically yes. I can't see us ever doing video in gnome-shell - we just
> have to be able to smoothly composite video someone else is playing.

(to be clear, that's what we do also.)

> But I'm not really thinking about gnome-shell here, I'm really thinking
> more about a "standard" application  perhaps Evolution or Rhythmbox.
> Whether written in GTK+ or in Clutter or some hybrid.

Agre

Re: Doubts about GPeriodic

2010-10-22 Thread Havoc Pennington
Hi,

On Fri, Oct 22, 2010 at 9:56 PM, Paul Davis  wrote:
> you guys are working out an incredibly complex and potentially baroque
> solution when the elegant and arguably "correct" one has already been
> implemented several times in different contexts. what's the point?
>

There's a lot of text in this thread but I think the resulting code at
issue is not large, dev time measured in days. Well what we're arguing
about is just a small patch once there's a paint clock. The paint
clock itself somewhat larger but still hopefully days. (Developer days
not calendar days.) We have significant prior art (clutter master
clock, litl shell, gnome shell, etc.) so it isn't from scratch, that's
part of why people have stuff to say about it. Heck I'm sure Ryan has
already finished the thing while we're discussing it here.

Changing over to having threaded rendering and GL-composited layers is
comparatively huge by 10x or 100x I would think, and hasn't even been
prototyped out by anyone. I could be wrong, as I said I haven't tried
to work it through other than idly thinking about it a little. Maybe
there is a simple version.

An important problem is more or less addressed by just the paint
clock, which is to be able to sync to hardware refresh and have a
tween timestamp related to that syncing. It's possible to get smooth
animation by just adding the paint clock.

As a practical matter what I'm going for is to get GTK to be sensible
when in-process with Clutter. The other stuff I listed at
http://log.ometer.com/2010-10.html#18 is part of that too. I just feel
like it sucks to continue the "to use Clutter you have to reinvent all
the GTK wheels" situation until GTK 4 and that it might not be such a
huge task to make GTK behave itself.

It may be that a possible approach to a render thread is to have
clutter in one thread and GTK in another thread layers are clutter
actors that GTK renders to... just idly thinking again ;-)  honestly I
have no idea how all this should work. Another question that keeps
popping up for me is why each process should have its own compositor
and then there's also an X compositing manager.

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


Re: Doubts about GPeriodic

2010-10-22 Thread Havoc Pennington
Hi,

On Fri, Oct 22, 2010 at 4:48 PM, Owen Taylor  wrote:
> I think we're largely agreeing on the big picture here - that priorities
> don't work so there has to be arbitration between painting and certain
> types of processing.

Right, good. The rest is really just details - there are various ways
it could work.

As I wrote this email I realized I'm not 100% clear how you propose
the 50/50 would work, so maybe it's something to spell out more
explicitly. There's no way to know how long painting will take right,
so it's a rule for the "other stuff" half? Do you just mean an
alternative way to compute the max time on non-painting tasks (half of
frame length, instead of 5ms or "until frame-complete comes back")?

> But pathological or not, I think it's also common. This is where my
> suggestion of a 50% rule comes in. It's a compromise. If we're lucky
> repainting is cheap, we're hitting the full frame rate, and we're also
> using 75% of the cpu to make progress. But when drawing takes more time,
> when there is real competition going on, then we don't do worse than
> halve the frame rate.
>
> (This continues to hold in the extreme - if redrawing is *really* slow -
> if redrawing takes 1s, then certainly we don't want to redraw for 1s, do
> 5ms of work, redraw for another 1s, and so forth. Better to slow down
> from 1 fps to 0.5fps than to turn a 1s computation into a 3 minute
> computation.)

Let me think about this in terms of litl shell, which is the
real-world example I'm thinking of, and maybe we can see how
gnome-shell or some other GL-using apps differ which could be
instructive.

Just to go over what's in there, you have your compositor; the most
intensive painting it does would usually be repainting video. But also
just has various GL eye candy animations and it has a lot of clutter
actors on some screens, so that takes time. Since lots of UI is in the
shell itself, compositing is not always what we're doing, sometimes
just a regular Clutter app really. Then crammed into this process, for
better or for worse:

 - "UI chrome" for out-of-process browser (toolbar in-process, actual
web page out)
 - global UI chrome (settings, switching between apps, etc.)
 - video chat stuff mixed in to the overall UI (the video chat engine
and video/audio playback is out of process, but has a lot of chit-chat
with the shell, it isn't an "app" but mixed into the global UI)
 - photos app that downloads photos from web then does GL-ish stuff to
display them (this is in process for the bad reason that drivers are
broken and out of process GL is/was fail)
 - playing audio bleeps and bings in response to UI interaction
 - chatter with a sqlite thread
 - chatter with the litl servers (over dbus, via the browser process)
 - chatter with gio threads
 - chatter over dbus about NetworkManager and whatnot
 - chatter over dbus to GTK widgets that are out of process (don't ask
but guess why I'm interested in certain GTK work ;-))
 - "misc"

I guess gnome-shell is similar except less "stuff"

As you say in the followup mail, at some point multiple
processes/threads exist for a reason.

Agreed, but in litl shell there's only one thing I think is in-process
that shouldn't be, which is the photo app, and one thing is out of
process that shouldn't be (GTK widgets). It's just a complex app
talking to a lot of other processes. All the main shell really does is
coordinate processes and paint an assemblage of the other processes. I
don't know, I would think it's basically the same deal as the "main"
Chrome process with every tab out of process, or as the main Eclipse
process where Eclipse has lots of threads, or whatever. The main shell
doesn't do blocking IO or long computations. It does have loads of IPC
queues to talk to all the threads and processes. I almost feel like
the threads and processes are the whole reason we have queue-based
GSource.

It almost seems like this is my prototypical case, where there *isn't*
any computation in the main thread, just lots of queues to dispatch,
and the case you're worried about most is where there *is* ... ?

On Radeon hardware with indirect rendering, litl shell paint takes in
the 7-9ms area. So for 60fps (16.6ms per frame) you have about 5ms per
frame leftover with a little headroom. On 50fps then you have more
headroom.

I'm not sure exactly what you're suggesting on the 50% rule; if it
strictly said 8ms instead of 5ms for the non-paint half, then that
sort of moves the practical numbers from "60fps with a bit to spare"
to "dropping frames" right? Most likely it isn't genuinely that big of
a deal because most frames don't hit the 5ms max, and even fewer would
hit the 8ms max, and we can start painting once there's nothing to do.
But there is sort of a qualitative difference between 5 and 8, which
is whether the painting still fits in the frame or finishes too late.

Ignoring the specifics, takeaways could be:
 * there's a cliff in the chosen time to spend not-painting where we
make ourselves miss

Re: Doubts about GPeriodic

2010-10-22 Thread Havoc Pennington
Hi,

On Fri, Oct 22, 2010 at 5:06 PM, Paul Davis  wrote:
> starting from scratch, and thinking about the parallels with a
> pull-model realtime audio design, it seems to me that if you were
> designing this entirely from scratch you wouldn't serialize painting
> and other source handling. you'd double buffer everything and run the
> paint/expose/vblank cycle in a different thread. whenever the
> non-paint/expose/vblank threads were done with refilling a new buffer,
> it would be pushed (preferably lock free) into a place where it could
> be used by a compositor and blitted to the h/w during the
> paint/expose/vblank iteration.
>

Right - Miguel pointed out to me (unrelated to this thread) that Mac
and Windows both work this way these days, and I'd already been
noticing that Chrome, new Pepper plugin API, lightspark, and probably
other stuff all seem to be moving to a "build a stack of
software-rendered layers then use GL to squish them" model. So
building a bunch of layers (ideally in threads) then GL-compositing
the layers (with optional transformations and shaders) seems to be
kind of the thing to do these days. You can animate the layers and
shaders totally in the GL thread without mixing up with the app code.

It seems like a big hairy change though. I definitely haven't taken
the time to start working it out.

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


Re: Doubts about GPeriodic

2010-10-22 Thread Havoc Pennington
Hi,

On Fri, Oct 22, 2010 at 10:28 AM, David Zeuthen  wrote:
> If you believe that the GUI thread should never perform blocking IO
> (such as reading from disk or IPC) or never perform CPU-intensive
> tasks (such as image- or video-decoding) then... then all that your
> code in the GUI thread does, is to receive data from one thread and
> maybe signal another thread.

This point only affects the "constant factor" though right, not the
basic character of what's going on.

If I have a spinner animation and that paints flat-out as fast as
possible without a "yield gap" to let other sources run, then that
_also_ starves a superfast main loop source that just sits there
grabbing messages and then throwing them elsewhere, just as much as it
starves a super slow main loop source. Speed is not the problem, it's
whether the source runs at all.

If you go the other way and want to starve painting if we're doing our
fast message throwing, then you're relying on always processing
messages faster than the other side can send them. Being "fast" is not
enough; it has to be "faster," i.e. it has to catch up and empty the
queue. In fact *all* active main loop sources have to happen to be
caught up *on the same iteration*. So if you're emptying three queues
you have stay ahead of all three senders at once and get them all to
zero at the same moment, and only then can you paint.

There's no special guarantee you can do that. You're relying on it
happening to work out.

Imagine two processes that are both following the rules and have 10
streams open to each other and they are both processing all 10 at a
superfast rate just tossing messages back and forth. What's the
latency between occasions where these processes have 0 sources to
dispatch? That drives your framerate. While 10 streams between two
apps sounds contrived, I don't think one big complex app with say a
sound server and some downloads in the background and some other
random main loop tasks is all that different.

> Anyway, my point really was something like this: If you want to talk
> about smooth animations and synchronoizing to vblank, it would
> probably be good for GPeriodic, Clutter and GTK+ to specify what
> people should and shouldn't be doing in the "GUI Thread" I know a
> lot of it is obvious to people on this list but it never hurts to
> write it down anyway.

With my "finite-length yield gap in the paint loop" approach, I think
you can do anything in the GUI thread as long as each single dispatch
is fast (and bounded in time). So you can't block, but you can do
anything that is _always_ pretty fast (you can't do things that are
_usually_ pretty fast, such as drain an unbounded queue, or blocking
IO that sometimes decides to hang for a bit).

That's how I'd document it.

The one thing that still breaks is if all your fast-dispatching
GSource add up to not-fast, since we have to dispatch all or nothing
at each priority. Solving that could be overkill though. File under
"someday."

With a yield gap, you need threads to block or to do an indivisible
long computation, but you don't need threads just because you have a
queue (or a divisible computation, which is basically a queue).

In the more classic approach (paint priority stays constant regardless
of time elapsed), I think you can do anything in the GUI thread as
long as:
- each individual dispatch is fast AND
  - (an animation is allowed to starve whatever you are doing
indefinitely so you can be below paint priority OR
  -  the sum of all dispatches that could occur in a single frame
timespan is fast and bounded. No queues. Long computations are no good
even if split up across dispatches. So you can be above paint
priority.)

it isn't clear that all long, but divisible, computations can be
tossed out of the UI thread. "filling a Tree/TextView" is a good
example of how "UI" vs. "not UI" is kinda fuzzy

To avoid queues in the main UI thread, you need both source and sink
to be threadsafe, and real-world unthreadsafe sources include say
libdbus, real-world unthreadsafe sinks include say GtkWidget.

One thing, it doesn't matter if paint priority is default or idle. The
issue is created when it's fixed with respect to "other stuff,"
instead of changing priority dynamically.

Anyway, yes, this only matters for a large complex app doing lots of
stuff in the same process as painting, while also trying to avoid
dropping frames. For any simple case, things just muddle through.

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


Re: threading / timers / etc

2010-10-22 Thread Havoc Pennington
Hi,

On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie  wrote:
>  - We will add GTimeSpec which is GTimeVal using nanoseconds instead of
>    microseconds (same story with struct timeval vs. struct timespec).
>    The librt interfaces provide this level of accuracy so it would be a
>    shame to needlessly discard it.

I know this is a completely minor side issue to the point of your
email (which sounds good overall) but I often find myself writing a
convenience wrapper around g_get_current_time() that returns a single
integer. If you do get_time(TimeSpec*) it might be nice to also do a
"uint64 get_time_milliseconds()" wrapper.

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


Re: Doubts about GPeriodic

2010-10-22 Thread Havoc Pennington
Hi,

On Fri, Oct 22, 2010 at 10:24 AM, Owen Taylor  wrote:
> Is painting well behaved? Inherently - no. We can easily get in
> situations where we can spend all our time painting and no time doing
> anything else.

That's the point of the up-to-5ms-of-dispatch thing (or the
wait-for-frame-complete thing), though, right? We can force painting
to be well behaved by having a period during each frame where painting
is not ready for dispatch or has a lower priority. During that period
anything else can run - even idles can run. (Or if we like, even
default idles can run but not low idles, or only default priority not
idles, could be implemented. Just has to be defined.)

I don't see the need to choose between painting-starves-everything and
everything-starves-painting.

The "dispatch everything but painting" gap can have a max length, not
a fixed length - if you do get everything else done you can proceed to
paint. (Well, that's what we do with the 5ms. I guess it might be
harder to do with a pure GMainLoop solution but you could do it, by
having the paint source dynamically change its priority or by having a
super-low-priority paint source that's always ready plus a
high-priority one that is only ready when frame-complete or after an
interval.)

The effect of max rather than fixed length "everything else" gap is
that if painting truly needs the whole frame interval (rather than
interval minus gap), painting may still keep up on those frames where
there's little else to do.

The idea is there's a period in which painting will be well-behaved by
yielding - it isn't allowed to defer everything else indefinitely /
100% of the time.

This changes your max time you theoretically have to paint from 1/fps
seconds to (1/fps - gap) seconds. However even if you can't paint in
(1/fps-gap) you will only lose a frame due to the gap when there's
really stuff to do inside the gap. And if you can't afford a
reasonable gap you probably really are hosed anyhow. There is already
a fixed max on paint time in order to look good, so that doesn't
change, the max is just tweaked (and can flex up to the absolute max,
1/fps, whenever possible).

The idea is that if your average paint-cpu and everything-else-cpu
adds up to less than 100% cpu, we shouldn't need to drop frames.
However with a starvation model, you drop frames even if you can keep
up on average, due to lumpiness, right? so that's the idea of only
yielding for a gap - if you get a lump in your everything-else, such
as a flood of messages, try to spread it over a few frames.

In practice I think that's what we're talking about. Say I have a
spinner animating smoothly, and I get some flood of IO or dbus or
whatever it is. Do I handle that flood in 30ms and my spinner hiccups,
or do I spread the flood in chunks over several frames, and my spinner
stays pretty. As an app developer I think what I want is the latter.
But I also don't want to wait for the spinner to go away before
handling this flood. I want to smooth the flood over multiple frames,
but not defer it indefinitely, I want to make progress on every frame.

I don't think that can be expressed by just having a fixed priority on
paint and a fixed priority on my handler; there has to be some way in
which the priorities "flip" during the frame.

> Are IO completions and IPC well behaved? Well that's really up to the
> application however, they have to be *somewhat* well behaved in any
> case.

What's hard I think is to make them well behaved in the aggregate and
on every single frame.

i.e. it's hard to avoid just randomly having "too much" to dispatch
from time to time, then you drop 3 frames, it just looks bad. But as
long as you're OK *on average* this can be solved by spreading the
dispatch of everything else across more than one frame, instead of
insisting on doing it all at once.

If you aren't OK on average, that's a problem the app is just going to
have to solve.

> If I have a GIO async callback that fills a treeview, there is one
> pathology where my callback gets called so frequently that we never get
> get to repaint. But what may happen instead is that I get so much data
> in a *single* callback that I block the main loop for an unacceptably
> long period of time. So we always will have the requirement that
> callbacks from the main loop must be *individually* short.

Yes. I think things can be made to work pretty well with just this requirement.

> Making IO
> completions and IPC highest priority makes this requirement a bit more
> stringent - it means that callbacks from the main loop must be *in
> aggregate* short. That callbacks from the mainloop aren't allowed to do
> expensive stuff, but instead must queue it up for an idle at lower
> priority.

A priority lower than paint is the right priority for most stuff, IMO,
as long as we're going to dispatch that lower priority at least for
some gap per frame. If the presence of an animation means that we
aren't going to dispatch lower-than-paint sources unti

Re: Doubts about GPeriodic

2010-10-21 Thread Havoc Pennington
Hi,

On Thu, Oct 21, 2010 at 5:47 PM, David Zeuthen  wrote:
> Note that with GDBus the resulting GDBusMessage is actually being
> built in a separate (and private) thread - so in practice there is
> zero overhead in the GUI thread - in particular it doesn't depend on
> what kind of message it is or how big the message is. The same is true
> for most of libgio's file and networking primitives (e.g.
> g_file_load_contents_async() will cause work to happen in a worker
> thread etc.).

I don't think this matters as long as there's effectively a queue in
the main thread (i.e. each message or IO chunk has a handler in the
main thread).

If you dispatch once per dbus message from an X-priority main loop
source, then lower-than-X-priority handlers will not run until there
are no dbus messages available. So if you are getting flooded with
messages, for example if a stream of data is being dbus-transmitted,
you would need to chew through that whole stream - _or_ it would have
to just happen that on one iteration of the main loop the message
processing had caught up with the message sending and the queue was
empty. Moreover that iteration would have to happen to have no other
X-priority sources ready. In that case a lower-than-X-priority
dispatch could occur. As the number of X-priority sources goes up
(think big complex app with plugins) the odds of getting no X-priority
sources on a given iteration would presumably drop.

As long as the main loop is seeing a stream of items with no
guaranteed pauses in the stream, in theory that main loop source runs
unbounded. (yes, in practice it usually doesn't run unbounded, but I
bet trying to hold 60fps will make the in-practice glitches more
visible)

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


Re: Doubts about GPeriodic

2010-10-21 Thread Havoc Pennington
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

2010-10-21 Thread Havoc Pennington
Hi,

On Thu, Oct 21, 2010 at 5:46 AM, Ryan Lortie  wrote:
>
> What about non-input events, though?  Like, if some download is
> happening and packets are coming in and causing dispatches from the
> mainloop that we do not have control over.

I brought this up a bit in the earlier thread.

My takeaway is that for I/O type stuff you usually want what we ended
up with at litl, which is to limit it to some length of time per
frame. Unfortunately GMainLoop has no native way to do that. I
described our solution a bit in the old paint clock thread.

There's a danger both of some random download starving animation and
of your download spinner starving the download.

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


Re: Doubts about GPeriodic

2010-10-21 Thread Havoc Pennington
Hi,

On Thu, Oct 21, 2010 at 4:26 AM, Emmanuele Bassi  wrote:
> no, the GL context should *not* be per window. multiple GL contexts
> usually pose more problems than they solve, in synchronization and
> context switching, on basically all drivers - except maybe on nvidia[0].

Fair enough, I didn't realize it was actually possible to do one
global context for all windows.

I would still argue for per-window (so we can shut down
unmapped/hidden windows and so widgets look at parent, not a global)

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


Re: Doubts about GPeriodic

2010-10-21 Thread Havoc Pennington
Another issue, seems like the ticker needs to be per-native-window:

* the GL context is per-window so the vsync mechanism also is

* we ought to shut down the ticker on windows that aren't visible

* each screen has its own vsync and the window is the normal
convention to imply a screen

* the general principle that widgets should be getting context and
state from parent widgets, in most cases ultimately from the toplevel
- but by chaining through parents. Rather than from global singletons
or state. attempted to explain in
http://log.ometer.com/2010-09.html#19 (so any gtk widget that's a
child of a clutter stage for example, would want to be asking that
clutter stage for paint clock)

Native windows would be either toplevels or embedded clutter/glarea
widgets, generally. But maybe just saying "any native window can have
its own clock" is right.

There probably shouldn't even be a global API because using it would
be broken, right?

When not actually using GL or vsync, then I think all native windows
could just inherit a single global ticker that would just be a
timeout, but that's more of an implementation detail than an API
thing.

Another thought, in the patch
   periodic->last_run = now;
I think this will look a little rocky - the frames are going to
display at actual-screen-hz intervals, no matter what time it is when
you record last_run and no matter what time it is when you call your
drawing APIs. So things look better if you keep the "tween timestamp"
on hz intervals. The last_run time probably has very little to do with
when frames hit the display. Animations should go ahead and paint
assuming they are hitting the display at a fixed fps.

In the litl shell fwiw the pseudocode for the tween time on each frame is:

int frame_time = 1000 / fps;
int actual_time =  - current_ticker_time;
int frames_late = (actual_time / frame_time) - 1;
current_ticker_time += frame_time;
 if (frames_late > 0) {
current_ticker_time += (frame_time * (frames_late + 1));
 }

The idea of this is: decide to drop frames based on floor(frames_late)
and then skip ahead by ceil(frames_late). The point of that is to bias
against dropping a frame until we're a full frame behind, but then be
sure we drop enough frames to get ahead a bit when we do drop them,
and always stay on a multiple of the refresh rate.

Due to this and also the desire to not explode when the computer's
clock is set, I would define the ticker to be a monotonic value that
is in time units but is not a wall clock time. i.e. if I change my
computer's clock back an hour, the ticker should keep marching
forward, and the ticker is allowed to be fudged to make animations
pretty.

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


Re: Docs for the gtk-style-context branch changes

2010-10-19 Thread Havoc Pennington
Hi,

On Tue, Oct 19, 2010 at 7:49 AM, Carlos Garnacho  wrote:
> * There is no intuitive replacement for gtk_widget_modify_*(). If we are
> to drop GtkStyle, I think that 3rd party libraries and apps implementing
> widgets could define regions and attach a GtkStyleProvider with the
> fallback priority to theme these, this way themes and users' CSS have an
> oportunity to theme these differently if they want, although others I've
> talked with think gtk_widget_modify_*() is handy API that shouldn't go
> away.

I think what's important here is that there's a quick/easy way to
"just set the color" on the widget.
Both the "foreground" and "background" color (currently you have to
know if fg is "text" or "fg" of course but no need to preserve that
distinction afaik)

The reason for modify_* was to fix this FAQ:
http://ometer.com/gtk-colors.html
That page still gets a fair bit of traffic from google, fwiw.

As long as you keep that FAQ from coming back (i.e. have some
reasonably obvious single-function-call way to "set the color of this
text or background") it ought to be fine.

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


Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

2010-10-17 Thread Havoc Pennington
Hi,

On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
 wrote:
>
> What happens when another subclass wants to use
> ->adjust_size_allocation() to realign itself further ? how
> can it cooperate with GtkWidgetClass and not cause bad side
> effects ?

In the patch I posted (assuming the FIXME is fixed), what would still be broken?
I'm sort of lost what problems are unsolved. Granted, I might find out
if I tested the patch ;-)

> ... and more importantly, why is this useful
> to anybody except GtkWidget and GtkContainer ?

It is useful in any abstract base class that wants to provide "stuff
around" whatever its subclasses draw.

I think GtkContainer is actually a good enough reason to have this.
border-width is deprecated sure, but it's not going away soon, it'd be
nice to clean up all the code that has to deal with it.

Another example in GTK is GtkMisc, though we want to deprecate that
too, you could use this vfunc to delete the align and pad handling
from its subclasses and delete some code, which would be nice.

Hypothetically you could do things like:
 * a base class that aligned in a more precise way than
left/right/center (like GtkAlignment)
 * a base class providing more complex CSS-like border/margin/pad
capability with colors for each
 * a base class that provided a frame
 * a base class that adds any kind of display or status next to subclass content

All of these could also be implemented as a container, granted. (That
is, GtkMisc and GtkAlignment solve the same problem.)
However, I think there can be good reasons to do this stuff in a base
class so your widgets can have the stuff "built in"

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


Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

2010-10-17 Thread Havoc Pennington
Hi,

Here's roughly what I'm thinking about. This is an untested patch with
a big FIXME in it (FIXME must be fixed to have a hope of working). But
I thought since you were poking at this I better share sooner than
later. Maybe there is some glaring problem here but just wanted to
communicate the code I was trying to describe.

One test of having this right is that it should be possible to make
GtkMisc work with adjust_size_* and rip manual align and pad handling
out of its subclasses. Of course, the implementation of GtkMisc would
look a lot like the code in GtkWidget's adjust_size_* but since you
could then "stack" Misc and Widget align and pad, it'd be a sort of
torture test.

Havoc
diff --git a/gtk/gtkcontainer.c b/gtk/gtkcontainer.c
index 30930e0..ba398f2 100644
--- a/gtk/gtkcontainer.c
+++ b/gtk/gtkcontainer.c
@@ -327,7 +327,10 @@ static void gtk_container_adjust_size_request  (GtkWidget *widget,
 gint  *minimum_size,
 gint  *natural_size);
 static void gtk_container_adjust_size_allocation (GtkWidget   *widget,
-  GtkAllocation   *allocation);
+  GtkOrientation   orientation,
+  gint*natural_size,
+  gint*allocated_pos,
+  gint*allocated_size);
 
 static gchar* gtk_container_child_default_composite_name (GtkContainer *container,
 			  GtkWidget*child);
@@ -1805,22 +1808,26 @@ gtk_container_adjust_size_request (GtkWidget *widget,
 
 static void
 gtk_container_adjust_size_allocation (GtkWidget *widget,
-  GtkAllocation *allocation)
+  GtkOrientation orientation,
+  gint  *natural_size,
+  gint  *allocated_pos,
+  gint  *allocated_size)
 {
   GtkContainer *container;
   int border_width;
 
   container = GTK_CONTAINER (widget);
 
-  parent_class->adjust_size_allocation (widget, allocation);
+  parent_class->adjust_size_allocation (widget, orientation,
+natural_size, allocated_pos,
+allocated_size);
 
   if (!GTK_CONTAINER_GET_CLASS (widget)->handle_border_width)
 return;
 
   border_width = container->priv->border_width;
 
-  allocation->width -= border_width * 2;
-  allocation->height -= border_width * 2;
+  *allocated_size -= border_width * 2;
 
   /* If we get a pathological too-small allocation to hold
* even the border width, leave all allocation to the actual
@@ -1830,22 +1837,14 @@ gtk_container_adjust_size_allocation (GtkWidget *widget,
* As long as we have space, set x,y properly.
*/
 
-  if (allocation->width < 1)
+  if (*allocated_size < 1)
 {
-  allocation->width += border_width * 2;
+  *allocated_size += border_width * 2;
 }
   else
 {
-  allocation->x += border_width;
-}
-
-  if (allocation->height < 1)
-{
-  allocation->height += border_width * 2;
-}
-  else
-{
-  allocation->y += border_width;
+  *allocated_pos += border_width;
+  *natural_size -= border_width * 2;
 }
 }
 
diff --git a/gtk/gtksizerequest.c b/gtk/gtksizerequest.c
index c3d0398..9ebb908 100644
--- a/gtk/gtksizerequest.c
+++ b/gtk/gtksizerequest.c
@@ -223,20 +223,58 @@ compute_size_for_orientation (GtkWidget *request,
   requisition_size = requisition.width;
 
   if (for_size < 0)
-GTK_WIDGET_GET_CLASS (request)->get_preferred_width (request, &min_size, &nat_size);
+{
+  GTK_WIDGET_GET_CLASS (request)->get_preferred_width (request, &min_size, &nat_size);
+}
   else
-GTK_WIDGET_GET_CLASS (request)->get_preferred_width_for_height (request, for_size, 
-  &min_size, &nat_size);
+{
+  int ignored_position = 0;
+  int natural_height;
+
+  /* FIXME getting unadjusted natural_height here is going
+   * to be annoying...  recompute it? pass it in? is it in
+   * cache?
+   */
+
+  /* convert for_size to unadjusted height (for_size is a proposed allocation) */
+  GTK_WIDGET_GET_CLASS (request)->adjust_size_allocation (widget,
+  GTK_ORIENTATION_VERTICAL,
+  &natural_height,
+

Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

2010-10-17 Thread Havoc Pennington
Hi,

I would think of it like this maybe

real_adjust_request(orientation, &request_data)
{
   adjust_request_by_adding_margin(orientation, &request_data)
  /* alignment does not affect request */
}

real_adjust_allocation(orientation, &allocation_data)
{
  adjust_allocation_by_removing_margin(orientation, &allocation_data)
  adjust_allocation_by_aligning(orientation, &allocation_data)
}

I think allocation_data *includes* the natural size, which is itself
adjusted. So when you by_removing_margin you are dropping down the
natural size you started with so that the align stuff has the
marginless size. Same for for_size.

Conceptually GtkWidget contains two adjustments. But those two
adjustments should not have anything to do with each other. It's as if
you had a hierarchy like:

GtkWidget -> GtkWidgetWithMargin -> GtkWidgetWithAlignment

Those would chain up to each other. But since it's all in one class
the two adjusts are invoked inline. However if our adjust vfunc has
the right signature, it should be possible to do margin and alignment
orthogonally.

On Sun, Oct 17, 2010 at 5:36 AM, Tristan Van Berkom
 wrote:
>  - Strip any padding added by itself and any subclasses from the
>    allocation->width (this produces a 'stripped_allocated_width')

Widget base class need not strip what subclasses added - each subclass
strips its own. When overriding, subclass has to chain up so widget
can do its stuff just as container does.

I'd also say "margin" here for clarity rather than padding

>  - If halign != FILL, it needs to limit the width to the real natural
>    size, this in itself involves:
>
>      a.) calling gtk_widget_get_preferred_width()
>

I think get_preferred_width should be called outside of the adjust
vfunc, and then initial natural size passed in. As the adjustment
proceeds, the natural size is chopped down by each adjustment.

>      b.) stripping any padding from the returned natural width
>          (producing a 'stripped_natural_width')

This should be done by the adjust_allocation_by_removing_margin() and
the natural width that then gets passed for aligning would be reduced.

>      c.) interior width available for alignments becomes
>          MIN (stripped_allocation_width, stripped_natural_width)

Hmm this doesn't sound right. Conceptually we have to decide if the
margin is inside or outside the alignment-required padding. This
basically means whether we do the margin adjust first or the align
adjust first. (Note that on request you go from inner adjust to outer,
i.e. chain up last, and on allocation the other direction, i.e. chain
up first. So if margin is on the outside, it would be added second in
request, and removed first in allocate.)

Anyway. What should come in to
adjust_allocation_by_aligning(&allocation_data) should be a natural
size de-margined and an allocation also de-margined. We just align the
de-margined natural size in the de-margined allocation.

>  - Now that we have the proper width for interior allocation; go ahead
>    and strip any padding added to the allocation->height, i.e. get
>    a 'stripped_allocated_height'.

I think you go back and have your unadjusted width allocation, and you
pass that as the for_width to the
adjust_allocation(orientation=height). Now as the allocation
adjustment proceeds, each adjust step has to also adjust for_width (in
addition to the allocation itself and the natural size).

> Of course furthermore, gtk_widget_get_height_for_width needs to be
> amended to adjust the for_width by:
>
>  - Stripping any extra padding added by ->adjust_size_request from
>    the for_width.

Rather, each adjust_size_allocation "step" (align, margin,
border_width are 3 "steps") should compensate for itself in the
for_width as the chaining up proceeds.

> That's the big picture of "what needs to happen", however it's still
> not mapped to any proper API... I've been tentatively writing some
> pseudo code that should do it but I keep getting stuck somewhere.

I think just adding the natural size, for_size, and orientation to the
existing two vfuncs should work. Probably need a struct to hold {
size, natural_size, for_size } which are the three things to adjust.

> There's also another alternative, all of this alignment/padding code
> so far belongs to GtkWidget (and marginally GtkContainer), so does all
> of the size-requesting logic... so we could go the direction of:
>
>  - remove vfuncs ->adjust_size_allocation/->adjust_size_request

I think the adjust approach should be workable as described above and
keep the nice encapsulation / flexibility of the vfuncs.

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


Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

2010-10-15 Thread Havoc Pennington
Hi,

On Fri, Oct 15, 2010 at 11:32 AM, Havoc Pennington  wrote:
>
> Without trying to code it and see if it works, it could look like:
>
> (* adjust_size_allocation) (GtkWidget *widget,
>                                       GtkOrientation orientation,
>                                       gint           *for_size_opposite,
>                                       gint           *natural_size,
>                                       gint           *offset,
>                                       gint           *adjusted_size);
>
> where all four numbers are changing as we're chaining 
> Widget->Container->Button
>
> Might be nicer to do struct GtkAllocatedSize { int for_size_opposite;
> int natural_size; int offset; int adjusted_size }  ?
>
> Sorry I got this wrong in my original patch :-/
>

A nice cleanup this could enable would be to just do the alignment and
margins completely separately in gtkwidget.c. i.e. gtkwidget.c would
effectively have two adjustments.

real_adjust_size_allocation(widget, orientation, allocated_size) {
   adjust_allocation_margin(widget, orientation, allocated_size);
   adjust_allocation_alignment(widget, orientation, allocated_size);
}

and same for request. i.e. "stack" the adjusts here, just as Container
stacks on Widget

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


Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

2010-10-15 Thread Havoc Pennington
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]

2010-10-15 Thread Havoc Pennington
Hi,

On Fri, Oct 15, 2010 at 9:55 AM, Havoc Pennington  wrote:
> I think you should just call the request methods again. (Not the
> wrappers of course, the vfuncs directly.) Instead of passing in a
> natural size.
>

I guess this doesn't work when chaining up and down

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


Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

2010-10-15 Thread Havoc Pennington
Hi,

On Fri, Oct 15, 2010 at 8:55 AM, Tristan Van Berkom
 wrote:
> The for_size fed to widget implementations additionally needs to
> strip the added padding that can happen in ->adjust_size_request()

Right, adjust_size_allocation should basically invert anything
adjust_size_request does so the widget is seeing things as if only the
widget itself had set the request.

By "padding" I don't just mean the margin properties, I mean anything
adjust_size_request adds (also the padding for fill alignment, the
container border width, etc.)

> However the bug I'm referring to is another one; the for_size also
> needs to be limited to the natural size in the case that the widget
> does not "fill" (i.e. not to compensate for pixels stripped in
> ->adjust_size_request(), but for pixels that will further be stripped
> in ->adjust_size_allocation(), in the case that the widget expanded).

Wouldn't it fix this to do adjust_size_allocation on the for_size?

> In the end the adjust_size_allocation() api/vfunc
> will look like this:
>
> void gtk_widget_adjust_allocated_size (GtkWidget *widget,
>                                       GtkOrientation orientation,
>                                       gint           proposed_size,
>                                       gint           natural_size,
>                                       gint          *offset,
>                                       gint          *adjusted_size);

If you have a for_size (which can be -1 for unset) then you could skip
the natural size and just call the size request API again, using the
for_size if >= 0. I think that would be better, because as you say:

> The part that feels weird here is that we are feeding in the
> natural_size, however it's important because come allocation time
> specifically; the 'natural_size' may be in context to a for_size
> in the other orientation (i.e. the widget cannot be expected to
> just "know" its natural size in this stage).

I think you should just call the request methods again. (Not the
wrappers of course, the vfuncs directly.) Instead of passing in a
natural size.

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


Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

2010-10-14 Thread Havoc Pennington
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

2010-10-12 Thread Havoc Pennington
Hi,

On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington  wrote:
> d) max size widget can do something useful with
> e) size at which widget acts like expand=false (this is what I'd call
> "max size" and I think it's a feature GTK doesn't have right now)

Trying to think about how these two are different, and not really
getting anywhere. It seems like you'd never set the max size above the
natural size.

So in the scrolled window case, to get the effect Matthias was going
for, maybe the answer would just be to set the max size hint on the
window to the natural size. The problem with that is basically
maximization and fullscreen, i.e. that we don't really want a max size
- it's better to add padding.

Conclusion perhaps, e) is not useful, user should always be able to
resize "too high" and get extra padding in the layout, if they want.

The situation where it could make sense to add max_size to
get_preferred_{width,height} might be if the natural size were defined
as c) "a good size", then you'd also be able to use a separate "max
useful size." For example then a box layout would first bring all
children up to the good size; if still extra space, then bring them
all up to max size; if still extra space, then start padding them.

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


Re: Minimum height for minimum width

2010-10-12 Thread Havoc Pennington
Hi,

On Tue, Oct 12, 2010 at 12:09 PM, Owen Taylor  wrote:
> I think you need to think very carefully about how natural width is
> explained and documented, since it seems to be neither exactly:
>
>  - the maximum useful width
>  - a "good width" for the widget
>
> I get the impression from the above that the main point of natural size
> is that once a widget reaches it's natural size it will stop competing
> with other widgets for space?

conceptually and in ascending pixel size I think there could be:

a) min size widget can be without breaking (breaking = drawing outside
bounds or whatever)
b) min size widget can be while being useful (still show some
recognizable info such as at least one word)
c) a "good size"
d) max size widget can do something useful with
e) size at which widget acts like expand=false (this is what I'd call
"max size" and I think it's a feature GTK doesn't have right now)

Coincidentally Matthias was just trying to invent e) on scrolled
window by dynamically changing expand flag (see
https://bugzilla.gnome.org/show_bug.cgi?id=628902), that just won't
work afaik, but we _could_ in theory add a max_size to
get_preferred_{width,height} which would do this at the cost of making
size request more complex to implement.

At the moment I'd say min size should be b) and natural size should be
d), but maybe there is a solid argument for c). I tend to think c)
should be done at GtkWindow or application level.

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


Re: Minimum height for minimum width

2010-10-12 Thread Havoc Pennington
Hi,

On Tue, Oct 12, 2010 at 11:40 AM, Tristan Van Berkom
 wrote:
> And currently the "min useful" is just not defined as
> "a single word width".
>

Understood, I think we basically agree.

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


Re: Minimum height for minimum width

2010-10-12 Thread Havoc Pennington
Hi,

On Tue, Oct 12, 2010 at 11:20 AM, Tristan Van Berkom
 wrote:
> I'm not sure what exactly you are talking about here, the only guess
> a label currently makes is for a reasonable "width-chars", i.e. limiting
> a wrapping label to a reasonably large minimum width. This is to avoid
> unreasonably large heights in proportion to the width.

search for guess_wrap_width in gtklabel.c, that's what I mean, i think
it's the same thing you're talking about.
That sets min size I guess, but I'm also saying we should have natural
size be max useful size, not another guess (related to earlier
discussion).
Basically I don't think min or natural should be a "guess what looks
good," they should be true min and max useful size.

>  b.) letting the user shrink the window's width too small and grow the
>      window's height too much (if we were to constrain window size
>      dynamically)

"too small" and "too much" here just means "somewhat unaesthetic
aspect ratio" rather than "broken." If the user wants to resize to
that, fine. Maybe their screen is a weird size. We shouldn't default
to it though, which is why GtkWindow needs more smarts.

If min size is two words per line instead of one word, ok, but
philosophically the min size should be the minimum size that's
remotely useful - NOT "size that looks pretty good" or "guess at a
nice aspect ratio"

Essentially, I don't think individual widgets should have much smarts
about this stuff. They should just report min remotely useful size,
max remotely useful size. Toolkit or app need to take steps to then
make the overall layout look good.

> Please explain where we are second-guessing stuff and how exactly
> the toolkit is broken, then we can move on to fix it.

I'm saying if the label needs any intelligence then we have a problem
because any other widget using h-for-w would also need intelligence,
and those heuristics may not even be compatible with each other or
make sense in the overall layout. Widgets should just be dumb about
this. Report their min and max useful size.

> So far the two things I would change (or add as enhancements) are:
>  a.) Add a feature to let the GtkWindow choose a default size
>      according to the natural size clamped into the screen size
>  b.) Try making the window's height constraint contextual to
>      the window's allocated width.

Yep I agree

> I wouldn't say the toolkit is broken just because we haven't yet
> added those features.

If making Label "dumb" (just reports min and max useful size) has bad
results, then that's a bug in the toolkit, or at least the app, or
some widget with more contextual knowledge like GtkDialog.
There isn't enough information on the Label level.

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


Re: Minimum height for minimum width

2010-10-12 Thread Havoc Pennington
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

2010-10-12 Thread Havoc Pennington
Hi,

On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom
 wrote:
> On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote:
>> On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote:
>> > Agreed, GtkLabel needs to report min size = true min sane size and
>> > natural size = either full width, or "a good width"
>> > The full width is more correct imo, maybe we should figure out why
>> > that doesn't work well.
>
>   I'm not sure you agree completely here, are you saying that a
> wrapping label's minimum width should be the width of the largest word ?
> or it should be a true sane minimum size ?

My point here was mostly about the natural width. I don't have a lot
of opinion about what min sane size is (though in general I think it
should be "smallest size that can work at all")

> I don't completely agree here either, in many cases that are important
> to handle the text displayed in a label is some user input, data loaded
> from a database or even some translated text that wont fit normal screen
> constraints (same goes for the natural width of a GtkCellRendererText).
>
> For this reason it is important for the programmer to consider setting
> "max-width-chars" on a label that may have overly large text.

IMO this should never be necessary unless something is broken. The
toplevel should pick a default size that's no larger than maximized
(work area) by default, if it can do so while staying above its min
size. (This may be an important addition to that "GtkWindow default
size = natural size" patch.) Widgets should not have to do a bunch of
custom f*ing around logic. They should report min useful size and max
useful size, done and done. If that doesn't work, the toolkit is
broken. Label trying to second-guess stuff to keep the toplevel aspect
ratio correct is just broken.

Now, we've just established that due to the WM interaction we may have
to be broken at least on X ... ;-) but hopefully the consequences of
that limitation can be minimized. In theory we could pretty quickly
get a new WM protocol in metacity/gnome-shell to fix it for real, too
- if we know what the protocol is, which I don't.

The only time I think you should have to do max-width-chars is when
you don't want the window to ever default to full screen width
(presumably you decide this is just ugly, for example). You shouldn't
have to set this to unbreak stuff - for example, you shouldn't have to
set it just to keep the window from going off the screen.

btw shouldn't max-width-chars be called natural-width-chars?

>> I certainly always saw the "good width to wrap to" thing as a workaround
>> for GTK+ 1/2 geometry management. But picking a good aspect ratio from
>> the toplevel will require a binary search. That might be fine if the
>> binary search is done only once when picking a default size for the
>> toplevel when first mapping it.
>
> Not sure where this portion is going, ofcourse setting the default width
> of a window to be the natural width of the window should be fine and
> doable, using reasonably sized labels and good judgement with
> "max-width-chars" this is currently doable.

I think a good first cut would be "natural width constrained to work
area size" - the WM may already do that constraint anyhow, hopefully.
Some windows might be sort of oddly wide compared to their height but
they won't go offscreen. Making things a pretty aspect ratio could be
done via binary search, but maybe is better done by just letting apps
set max-width-chars or otherwise messing with their layout. Doing it
by magic picking of a "good wrap width" by default ... eh. Such a
weird hack.

> One thing I have to add is that constraining the width of the window
> to be the natural width of the window is surely not what we want; It
> would mean that minimum sizes of labels are then unattainable
> completely (in which case, why have a minimum size at all ? the minimum
> then becomes the natural for the whole window's content).

I don't think anyone was suggesting this

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


Re: Minimum height for minimum width

2010-10-11 Thread Havoc Pennington
Hi,

On Mon, Oct 11, 2010 at 3:30 PM, Owen Taylor  wrote:
> Setting the hints dynamically based on the current width can work, if
> we're willing to say "screw wireframe resizing" (wireframe resizing
> doesn't completely *not* work, you just have to release and retry
> a few times to get to certain sizes.)

Uggghhh... so the h-f-w request/allocate stuff needs to be exposed to the WM ;-)

I can't even think of a good solution in theory, offhand. I guess
having labels pick a "good" width is the best option.

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


Re: Minimum height for minimum width

2010-10-11 Thread Havoc Pennington
Agreed, GtkLabel needs to report min size = true min sane size and
natural size = either full width, or "a good width"
The full width is more correct imo, maybe we should figure out why
that doesn't work well.

A related patch attached, if you fix this you'll quickly want it.

Also, you said if doing minimum-height-for-natural-width the window
doesn't wrap the label and can't be made narrower. I don't understand
that... I would expect the min size of the window is the min height
for natural width as you propose, and the min width as returned by
get_preferred_width(). So the min width ought to be the true min
width?

Hmm. The "a good width to wrap to" thing seems like pretty much crack
to me. If people want their window to have some sort of pleasing
aspect ratio they should just pack the label to limit its width, or
set default size on the window, or whatever. Or maybe GtkWindow should
constrain the default size to "nice aspect ratio" somehow, solving
globally for the window instead of per-label.

Havoc
From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001
From: Havoc Pennington 
Date: Mon, 6 Sep 2010 11:18:35 -0400
Subject: [PATCH] Make GtkWindow default to natural size not minimum size

Otherwise your ellipsized labels all start out ellipsized, unless
you manually gtk_window_set_default_size().

This probably makes it important to clamp the window's default
size to the size of the monitor's work area.
---
 gtk/gtkwindow.c |4 ++--
 tests/testgtk.c |1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/gtk/gtkwindow.c b/gtk/gtkwindow.c
index 5f75dae..b50a9ab 100644
--- a/gtk/gtkwindow.c
+++ b/gtk/gtkwindow.c
@@ -5725,9 +5725,9 @@ gtk_window_compute_configure_request_size (GtkWindow *window,
   
   if (window->need_default_size)
 {
-  gtk_widget_get_child_requisition (widget, &requisition);
+  gtk_size_request_get_size (GTK_SIZE_REQUEST (widget), NULL, &requisition);
 
-  /* Default to requisition */
+  /* Default to natural requisition */
   *width = requisition.width;
   *height = requisition.height;
 
diff --git a/tests/testgtk.c b/tests/testgtk.c
index cddb7df..8ea1117 100644
--- a/tests/testgtk.c
+++ b/tests/testgtk.c
@@ -8431,6 +8431,7 @@ create_window_sizing (GtkWidget *widget)
 			 gtk_widget_get_screen (widget));
   label = gtk_label_new (NULL);
   gtk_label_set_markup (GTK_LABEL (label), "Window being resized\nBlah blah blah blah\nblah blah blah\nblah blah blah blah blah");
+  gtk_label_set_ellipsize (GTK_LABEL (label), PANGO_ELLIPSIZE_END);
   gtk_container_add (GTK_CONTAINER (target_window), label);
   gtk_widget_show (label);
   
-- 
1.7.0.4

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


Re: GtkGroupBox and layout ideas for Gtk3

2010-10-10 Thread Havoc Pennington
Hi,

On Sun, Oct 10, 2010 at 4:57 PM, Alexander Larsson  wrote:
> First of all, what happened to Bug 628902 "Add expand flags to
> GtkWidget". It seems to have stalled. This would be very useful.
>

The latest code is on widget-expand-3 branch, fwiw.

todo items are:

* magic resizability behavior on GtkWindow
* write equivalent of GtkBox patch for Table
* remove expand child prop from WrapBox (if we keep wrap box, I guess)
* possible "do not propagate" special cases see
https://bugzilla.gnome.org/show_bug.cgi?id=628902#c24

I think all of these are trivial 10-minute kind of patches except the
first one. I'm not sure when I can tackle that task... may be a while.
I got tied up in non-GTK stuff again and for GTK I feel like more
urgent would be to get all the non-toplevel non-plug/socket widgets
off of GdkWindow (step 1 the "events for no window" thread delete
input only windows, step 2 figure out clipping and scrolling delete
remaining windows, step 3 profit).

I'm not sure magic GtkWindow resizability is required to land the
patch. If it's done such that setting geometry or resizability always
overrides what the expand propagation would dictate, then it may even
be ABI compatible. On the other hand, the GtkWindow changes may not
really be that hard. I just haven't looked into it and there are a
whole bunch of weird cases GtkWindow handles that would be a pain to
test. But it may only take somebody a day or less.

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


Re: grid widget (was Re: possible removal of GtkWrapBox)

2010-10-10 Thread Havoc Pennington
Hi,

On Sun, Oct 10, 2010 at 10:41 AM, Tristan Van Berkom
 wrote:
> I would only expect the expand to be distributed evenly among
> children as, thats what GtkBox does ;-)

But the whole point of the exercise is to mop up GtkBox cruft...

> I'm not sure that having all the children stop expanding
> when an expand child is added is any worse than having all
> the extra column/row spacing suddenly disappear.

The general principle I think is that if a child doesn't say it can
benefit from expand, it doesn't make sense to expand it. For example,
expanding a button just looks bad.

> Maybe a similar spreading option would be useful for the Grid ?
> (i.e. decide whether Grid children EXPAND, or line up at the START
> or END, or get spread EVEN)...

You can use widget halign/valign to do START and END right? Then Grid
never gets extra allocation.

The only case where Grid needs something "special" is if it does get
extra allocation, i.e. it is align=FILL.
In that case, if there are expand children, obviously extra allocation
should go to them.

If there are no expand children, then the two choices are to allocate
extra space evenly to the children, OR allocate extra space as spacing
between the children.

Allocating extra space "around" the children is redundant with setting
halign/valign on the grid so I think that is a pointless feature.

Allocating extra space evenly to the children I think is redundant
with setting expand=true on the children.

So the only thing that can't be done already is to allocate extra
spacing in between the children. You can then get any of the effects:

a) no expand=true children, grid align = FILL: extra allocation
becomes spacing between children
b) any expand=true children, grid align = FILL: extra allocation goes
to the expand=true children only
c) no expand=true children, grid align = START | CENTER | END: extra
allocation is spacing on one side or both sides of grid

If it works like GtkBox, then in case a) you just pretend it is case
b) with all children set to expand=true. This means:
 - there's no way to do a) anymore unless you add some special option
 - the behavior is illogical (widgets with expand=false expand anyway,
until you set one to expand=true then they don't?)

The simple obvious thing is: children expand only if they are expand=true.

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


Re: grid widget (was Re: possible removal of GtkWrapBox)

2010-10-10 Thread Havoc Pennington
Hi,

On Sun, Oct 10, 2010 at 6:36 AM, Tristan Van Berkom
 wrote:
> bottom or right size of the Grid. (if the user wants the
> grid children not to expand at all, they should only have
> to pack the whole grid into another container and say that
> the grid does not expand).

Or set halign/valign on the grid to something other than FILL right?

I would expect that if the grid gets an allocation above its request,
that allocation goes first to any expand children, and second just
centers everything, or creates extra space evenly distributed around
non-expand children, perhaps. Actually expanding the non-expand
children seems weird (not least because it means as soon as you add an
expand child, all the other children stop expanding when they did
before).

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


Re: grid widget (was Re: possible removal of GtkWrapBox)

2010-10-07 Thread Havoc Pennington
Hi,

On Thu, Oct 7, 2010 at 1:18 PM, Federico Mena Quintero
 wrote:
> However, who writes UIs by hand these days?  Doesn't everyone just use
> Glade?

It's a valid point, but I don't know that Glade is always easiest. I
don't think it's a good excuse for making the actual API crappy.

(In fact I'd almost think Glade should have its own container widget
that's designed to be easy to use in a builder, just as in code it's
good to have a container widget that's easy to use in code. Do the
same top-down exercise with Glade - what would make a container easy
to work with in a UI builder - and design based on that.)

> I don't know how many other examples you considered while thinking about
> your API, but let's see about those three:

I knew these were built into gtk and probably ui files, but I still
think they're good examples of reasonably complex layouts that show
some of what people want to do.

> * Our HIG-beloved sections with indented contents in dialog boxes.
> There is no official solution to this, and various apps do different
> hacks to achieve them.

I was thinking this could be built into Grid, but it's normally done
with a frame right? Which seems OK too except that Frame's defaults
don't match what's wanted. Possibly needed here is a GtkBin that looks
the GNOME HIG way on Linux and a windowsy/mac-y way on other
platforms.

> If you are making your UIs with Glade, it would help for Glade's
> usability to be improved in a similar fashion.  We should study what
> kinds of tricks people use to rearrange widgets... creating a temporary
> window, inserting a container, then cutting&pasting widgets into it to
> create a holding space, is pretty cumbersome.

Exactly, doing an interaction design of how layout should be done in
Glade, then designing a widget just for that... would be awesome.

Maybe the easy-to-code widget matches the glade widget, I don't know.

Not saying we'd hide the glade widget from code or hide the code
widget from glade, just that it might make sense to have a widget
optimized for those two cases.

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


Re: grid widget (was Re: possible removal of GtkWrapBox)

2010-10-07 Thread Havoc Pennington
Hi,

On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom
 wrote:
> However I would really appreciate it if a widget's placement
> inside a container can still be clearly introspected and defined
> with container child properties (in other words I think the widget
> should be built with child properties and the 'cursor' be a
> convenience API layer of sorts).
>

I agree with this (and almost mentioned it).

I guess what I'd say though is, I think the "gridbuilder" should be
the primary/expected API when packing with code, and taking the API
design "top down," the child properties have to be designed such that
the nice gridbuilder is possible.

I wouldn't really do the gridbuilder as a literal separate API
("gtkgridbuilder.h"). I think it would add typing and confusion. I'd
say go ahead and make it gtk_grid_add_left(), etc. which would be the
first API people go for. And then the "raw" child props API could even
be _just_ properties (use gtk_container_add_with_properties etc) or
just a couple of low level functions that would be documented as "you
probably don't want to use this"

One question on gridbuilder is whether it's "persistent." For example,
it could be that as I'm doing add_left(), add_row(), etc. that is just
setting fixed grid coordinates. And then once the grid is created, I
can't use the gridbuilder stuff to modify it. Or, it could be that as
I do add_left(), add_row(), etc. that is saving a conceptual list of
actions and on each relayout, that conceptual list of actions is
converted to a table of cells.

I think it's maybe the second thing for two reasons:
* you can then use "gridbuilder" API to modify the table later. an API
could allow you to "set the cursor" to a particular row and next to a
particular widget, then you start "gridbuilding"
* you need to autocompute table size, so when doing add_left, add_row,
etc. you don't know the actual cell coordinates yet

It isn't totally clear to me what the right child properties are.

Kind of the way I'd approach this would be to have some sample layouts
that were typical and Should Be Easy(tm), write nice, logical,
non-redundant code that should produce those layouts, then figure out
how to implement the widget to support said nice code.

Hmm. One other goal ideally achievable, is that a simple one-row box
should not have a ton of CPU or memory overhead.

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


Re: grid widget (was Re: possible removal of GtkWrapBox)

2010-10-07 Thread Havoc Pennington
Oh, another thing to have is probably h-spacing and v-spacing for the
grid-wide space between rows and columns. For per-column or per-row
spacing you could use a margin or a spacer widget placed on that row
(?)

If not clear the idea of the exercise I was doing is to figure out how
you'd naturally describe a layout, say to another person, in logical
terms and without redundancy.

So examples of things I think you would not do if talking to a person
or just thinking logically include:
 * doing the pack_end widgets backward
 * positioning widgets using grid coordinates

One litmus test for "too much redundancy" is if you have to change two
lines to add or remove a widget. I think to put another widget on a
row or to add another row, you should be able to add one line of code
without changing other lines, at least in the typical case. Similarly
to remove a widget or row, you should just delete the corresponding
line of code.

GtkTable requires you to change both the table constructor (overall
table size) and _then_ possibly re-number a bunch of the other
children, so it epic fails this litmus test.

Another idea, the "cursor" thing could be done explicitly:

 GtkGridCursor cursor;
 gtk_grid_cursor_init(grid, &cursor, row=0);
 gtk_grid_add_row(grid, &cursor, child);

But it seems like extra typing for not much good reason.

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


Re: GtkSpreadTable ('spread-table' branch)

2010-10-07 Thread Havoc Pennington
I think a picture would be helpful ;-)

Are we sure this is of general interest? It seems like something only
a few percent of apps would end up using.

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


Re: GtkSpreadTable ('spread-table' branch)

2010-10-07 Thread Havoc Pennington
Hi,

Oh, I see now it's a WrapBox replacement I guess (reading threads out of order)

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


Re: paint clock

2010-10-04 Thread Havoc Pennington
Hi,

Maybe the very very simple first step that punts on all the hard stuff
is to do a queue-redraw virtualization like this:

http://git.clutter-project.org/clutter/commit/?id=961aac3fb36f73d4a48720d93b8928a3e24b5b84

The default implementation of this in GtkWidget would invalidate on
GdkWindow, but something like clutter gtk could override and ignore
GdkWindow entirely and use a paint clock.

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


Re: paint clock

2010-10-02 Thread Havoc Pennington
Hi,

On Sat, Oct 2, 2010 at 7:32 PM, Soeren Sandmann  wrote:
> FWIW, I put up the notes I wrote about this subject here:
>
>        http://www.daimi.au.dk/~sandmann/framehandlers.txt
>
> They were written with a different toolkit than GTK+ in mind, so they
> make various assumptions that don't apply to GTK+. For example the
> widgets are assumed to not do anything like gdk_window_process_exposes().
>

Very interesting!

We've messed with various things smarter than what I described for litl shell.

Right now it's "do stuff for up to 5ms only if there's anything to do;
then paint immediately." This gets throttled by the vsync. We never
install a timeout or sleep as long as we have a paint queued.

We had terrible luck with anything that involved installing a timeout
(i.e. polling with nonzero timeout). In part this may be that the
shipping litl product is based on 2008 or so Linux which I believe has
10ms resolution on poll timeouts... so the noise in timeouts is
already half a frame. This just can't end well. I believe newer
kernels have high-resolution timeouts though... all I know on this
subject is from
http://lwn.net/Articles/296578/

I think another issue here was that frames are just not that uniform.
Some frames have a bunch of crap that happens to happen, like incoming
IO, some have none; or some frames might have to upload a texture or
something and then the next 10 frames don't have to do that. It isn't
very predictable. litl shell is a number of different apps plus a
compositing/window manager all crammed into a single process so it may
have had more trouble than most things.

In short we haven't managed to dynamically pick the 5ms number. But
just setting it to 5ms seems to work pretty well.

Another number that we've tried to get clever with but failed is the
frame timestamp used for tweening. You have this correct in your
document of course.  The thing that's tempting is to use actual wall
clock time. But it seems to be true that animations are prettier if
you just add the frame length to it every time, and if the result gets
"too far" (for us, 1 frame) behind the wall clock, skip ahead by whole
frame intervals thus dropping frames. I guess the reason is that vsync
is always going to show the stuff at exact frame intervals, so using
any frame timestamp not on those intervals is just wrong. Anyway this
is one reason why GtkImage animations and the "traditional JavaScript
technique with Date.now()" described in roc's mozRequestAnimationFrame
post are inherently not smooth looking. The lag between generating the
frame and getting it on the screen is enough to make wall clock time
when generating almost irrelevant.

I kinda think "snap wall clock time to multiples of frame_length for
tweening" will look pretty good even if the app has no awareness of
when the vsyncs actually happen, as long as the refresh rate is known
you have a good chance that each of your frames will show up and that
you'll get a different frame on each vsync. For example even in a
non-GL GTK, if GTK queried the refresh rate (e.g.
XRRConfigCurrentRate()) and used that for the paint clock, I bet it
makes GTK animations look way nicer than they do now.

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


Re: paint clock

2010-10-02 Thread Havoc Pennington
Hi,

On Sat, Oct 2, 2010 at 8:57 PM, Matthias Clasen
 wrote:
> If we move to a fixed order of doing things each frame, like Owen
> described here:
> http://blog.fishsoup.net/2009/05/28/frames-not-idles/

A link I obviously should have included, thank you

>, then the paint
> clock could perhaps just have those before/after hooks as signals (as
> you already have for paint). If we make animation, input handling and
> relayouting a fixed part of the frame cycle, then it is not really a
> 'paint' clock anymore.

Right. Well I was thinking relayout and update-tweens could maybe be
done just by connecting to the before-paint signal in the
GdkPaintClock. But maybe it's better to have specific signals for
relayout and update animations. Among other things that would put them
in a deterministic sequence. (and relayout definitely has to be last)

Maybe "master" clock or "frame" clock would be better names. I don't
think "paint" is wrong (it _is_ all driven off of repainting, tying
everything else to repaint is the point) but clearest name I don't
know.

Also I hadn't really thought about special-casing X event processing,
even though it's the obvious thing to do since Clutter does it, litl
shell does it, and Owen discusses it. litl shell also takes a crack at
the motion event stuff (though we do it by always using motion hint
mask and then doing QueryPointer on each frame if we got a motion,
rather than by discarding all but latest event per frame). We just
discard the QueryPointer reply, though perhaps it would be better to
use it to synthesize a motion event if no actual motion event appeared
for the frame.

One issue is what to do about "other" stuff (not X events, not
resizing, not tweening animations, and not painting)

litl shell runs the other stuff for at least 1 mainloop iteration per
frame, plus more iterations until we've spent 5ms. 1 iteration per
frame of course means all highest (usually default) priority stuff is
guaranteed to dispatch once, so one event or one message or one read()
off an incoming fd or whatever, per source.

Clutter runs the master clock mainloop source as a high idle, so I
believe they would allow any default-priority stuff to starve repaint,
but would never run idles during an animation.
litl shell is happy to run an idle within the 5ms window, but will
stop running default-priority stuff (more than one iteration anyway)
if we exceed 5ms. Not sure the details matter that much here as long
as you have enough performance headroom to be pretty reliably hitting
your target framerate.

GDK's current repaint handler is a high idle also, same idea as
Clutter I guess. GDK then has X events at normal priority so it is
always dispatching all events prior to any repainting.

Looks like gdbus and gio's GSimpleAsyncResult use default priority, so
loading files or talking to other apps are by default treated as
equivalent to X events. It's possible these things should really be at
idle priority, but it sort of depends on the use-case.

I kind of like the idea of limiting "doing stuff" to a fixed time
window before we force a repaint. Having the paint clock main loop
source use a "popping priority" where it does g_source_set_priority on
itself on the fly may actually work I think - gmain.c doesn't seem to
say you can't do that. ;-)

I don't really like the idea of starving non-painting (even idles)
completely just because there's some cheesy animation somewhere in the
frame. Just doesn't seem probable anyone ever wants this. I also don't
really like the idea of starving repainting completely just because
there's a bunch of IO or IPC going on. So in short to me the priority
system doesn't seem expressive enough unless something dynamically
changes its priority. What's wanted is that we give other stuff
priority for "a few ms" and then we force painting to be top priority.

It seems like current GDK and Clutter imply that very little should
ever use default priority, because delaying repaint for more than a
few ms is just fundamentally not OK in most GUI apps. And even if your
default-priority thing is relatively fast, at some point in a big app
you have N default-priority things, and the paint loop has no ability
to limit how many times it dispatches the default priority stuff.
(With GMainLoop there's no way at all to avoid dispatching
all-or-nothing at a given priority, but at least if you have 30
default-priority things, you can dispatch the 30 only once instead of
however long it takes for all 30 to be unready. I think even better
might be to be able to dispatch one GSource at a time and then break
out of dispatch, but who knows what wild implications that has.)

As a practical matter, of course, a GSource dispatch is free to take
100ms to do its thing, and so we're doing cooperative multitasking
here; and if performance just fundamentally isn't keeping up, then
things get hosed no matter how scheduling is done.

But it'd be nice to avoid "accidental total catastrophe." We had a bug
in litl s

Re: paint clock

2010-10-02 Thread Havoc Pennington
Hi,

On Sat, Oct 2, 2010 at 6:37 PM, Xavier Bestel  wrote:
> * how do you handle multimonitor setups where an application can have 2
> different vblanks to care about ?
>

Separate paint clock per toplevel, I guess. The approach in the patch
of gdk_window_set_paint_clock() would support that. It sort of
requires a nonblocking buffer swap though I would think.

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


Re: GTK3 breakage

2010-09-26 Thread Havoc Pennington
Hi,

2010/9/26 Javier Jardón :
>
> It returns a pointer to a GObject now
>

Shouldn't it just return a GtkAdjustment* ? returning GtkObject was
some weird legacy thing.

Also, isn't gtkobject still there in master?
http://git.gnome.org/browse/gtk+/tree/gtk/gtkobject.h

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


Re: events for no-window widgets

2010-09-22 Thread Havoc Pennington
A couple other ideas, just to put more options in the pile.

Minor concern. gdk_event_set_coords() and set_source() could be
problematic in that GdkEvent would become a mutable non-GObject. This
is normally considered Bad language-binding-wise. Though in this case,
the implications are perhaps limited since events don't "stick around"
and multiple proxies for one event would probably be OK.


Another API for getting events to no-window widgets, would drop
GdkEvent for this, and add something like:

/* pretend these are opaque objects with accessors but that's too much
typing in this email ;-) */

typedef struct {
  gdouble x, y; /* widget relative */
  GtkWidget *source;
  GdkDevice *device;
  /* rest of any useful fields here */
 GdkEvent *event; /* original event in case you need window or root
relative, or whatever */
} GtkButtonPress;

struct GtkEventReceiverClass {
void (* button_press) (GtkEventReceiver*, GtkButtonPress*); /* this
bubbles the button press. */
}

There could or could not be a "base class" for GtkButtonPress,
KeyPress, etc. and a "base signal" ::bubble that was emitted for all
of them. It could be that each button_press, button_release, etc.
bubbles separately with its own vfunc directly. Without the base
class, you never actually have to name this GtkEvent or use the word
event, which avoids some of the namespace collision.

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


Re: events for no-window widgets

2010-09-22 Thread Havoc Pennington
Hi,

On Wed, Sep 22, 2010 at 10:28 AM, Matthias Clasen
 wrote:
>
> Isn't that handled by containers simply not calling draw on covered up
> or hidden children ?
>

yeah, quite possibly. Especially if we move animations into a magic
master clock that would also be stopped.

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


Re: events for no-window widgets

2010-09-22 Thread Havoc Pennington
Hi,

On Wed, Sep 22, 2010 at 8:55 AM, Paul Davis  wrote:
>
> i think you might want to consider MAP and UNMAP

I was thinking the vfuncs (already called on no-window) and map/unmap
signals would be fine. i.e. I agree map is interesting for no-window,
but I don't think ::map-event adds anything over just ::map, does it?

> (and possibly
> VISIBILITY_NOTIFY too) as being in section A2. i know that as they
> stand, these refer to GdkWindows, but by implication they also apply
> to widgets within the window.

Some kind of "are we covered up and do we need to paint" flag could be
interesting

> in addition, is it really true that drag events are of interest only
> in the context of GdkWindow or GdkDisplay?

It looks to me like drag events are all handled globally in gtkmain.c,
gtkdnd.c and end up converted to signals on GtkWidget (events are not
sent to GtkWidget right now). I didn't look super closely though.

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


events for no-window widgets

2010-09-21 Thread Havoc Pennington
Hi,

I've been exploring how widgets with no GdkWindow could receive
events. Here are some notes so far in case people have thoughts.

Event Types
===

Events separate very cleanly into "weird lowlevel stuff only matters
for GdkWindow" and "things widgets in general including no-window
widgets care about"

A. Events all widgets care about have two subdivisions:
A1. events that bubble: GDK_MOTION_NOTIFY, GDK_BUTTON_PRESS,
GDK_2BUTTON_PRESS, GDK_3BUTTON_PRESS, GDK_BUTTON_RELEASE, GDK_SCROLL,
GDK_KEY_PRESS, GDK_KEY_RELEASE
A2. events that are glorified property notifies: GDK_ENTER_NOTIFY,
GDK_LEAVE_NOTIFY, GDK_FOCUS_CHANGE

B. Freaky events of interest only in context of GdkWindow or GdkDisplay:
GDK_DELETE, GDK_DESTROY, GDK_EXPOSE, GDK_CONFIGURE, GDK_MAP,
GDK_UNMAP, GDK_PROPERTY_NOTIFY, GDK_SELECTION_CLEAR,
GDK_SELECTION_REQUEST, GDK_SELECTION_NOTIFY, GDK_PROXIMITY_IN,
GDK_PROXIMITY_OUT, GDK_DRAG_ENTER, GDK_DRAG_LEAVE, GDK_DRAG_MOTION,
GDK_DRAG_STATUS, GDK_DROP_START, GDK_DROP_FINISHED, GDK_CLIENT_EVENT,
GDK_VISIBILITY_NOTIFY, GDK_NO_EXPOSE, GDK_WINDOW_STATE, GDK_SETTING,
GDK_OWNER_CHANGE, GDK_GRAB_BROKEN, GDK_DAMAGE

Unfortunately, the current ::event signal (and per-event-type
sub-signals) dump all this together. These are logically very distinct
and ideally if we were starting from scratch, I would probably want to
see:

A1. a "GtkEvent" with some of the obscure lowlevel fields removed, no
->window field, add ->widget field, coords are widget-relative
A2. just use property notifies on "contains-pointer" and "has-focus" properties
B. GdkEvent as it is now (well, cleaned up, but similar idea)

Splitting out B (Window Owners)
===

A challenge is to think about all code related to B as conceptually a
new type, GtkWindowOwner or something. The only instances of this type
would be GtkWindow, GtkPlug, GtkSocket, and maybe a couple other
"weird" widgets like GL area. Unfortunately this type is sort of a
mixin; if it were an abstract base class, then widgets could not be
both a GtkWindowOwner and a GtkContainer. This probably means that the
WindowOwner functionality has to remain in GtkWidget.

Stuff that belongs to the conceptual window owner type could include:
the signals for all the B events; event mask; set_window;
set_double_buffered; GdkVisual; style_attach(); shape mask.

I don't think this stuff can easily be actually split out of
GtkWidget. However, I do think it's helpful to think of it as
distinct. _Possibly_ it would be clearer to add an interface that
explicitly had all this, and make GtkWidget implement that interface,
and deprecate the old gtk_widget_ names someday.

Or maybe there's a nice solution involving delegation, where window
widgets have a helper object and there's a base class for that.

Enter/Leave Notify
===

Here is how I think enter/leave should work:
http://bugzilla.clutter-project.org/show_bug.cgi?id=1576

Though I'm not sure events are required at all. Currently, something
like GtkButton needs the input-only window just to prelight. I think a
simple boolean property "button or any child of button contains
pointer" would be sufficient for this, however.
Multiple GdkDevice pointers complicates that a bit, though it doesn't
look like GtkButton handles that right now. The boolean could be
defined to mean that greater-than-zero devices are inside the widget
and that would probably work fine for prelighting, better than the
current enter/leave events in fact.

My current thought here is to have a boolean prop which is set on the
leaf widget containing each device and all ancestors of that widget.
For convenience, maybe a vfunc or vfunc pair which is invoked whenever
this property changes. notify::contains-pointer would already be a
signal for it but that's sort of annoying in subclasses.

I guess this flag would simply mean "prelight" and that might be handy
for the new theme stuff.

Given the property, the event would be only on conceptual
GtkWindowOwner. No-window widgets would use the property not the
event.

Implementing "contains-pointer" for no-window widgets would require
some kind of pick() virtual method for identifying the widget under
the pointer, GtkWidget default implementation just looks at widget
allocations, GtkContainer default recurses into its children. Picking
would start at the window widget receiving a GdkWindow native motion
notify or enter/leave and then generate synthetic events for no-window
widgets inside that GdkWindow.

Focus Change
===

I believe the existing has-focus pretty much handles this; similar to
the above-proposed notify::contains-pointer, it might be handy to have
a virtual function to go with it, or virtual function pair. The fields
in the focus change event are only of interest for GtkWindowOwner not
for widgets in general, it looks like.

Given the property, the event would be only on conceptual
GtkWindowOwner. No-window widgets would use the property not the
event.

Bubble Events
===

If we solve "A2" enter/leave/focus events with properties, "

Re: rendering-cleanup-next

2010-09-16 Thread Havoc Pennington
Hi,

On Thu, Sep 16, 2010 at 6:36 AM, Andrew Cowie
 wrote:
> On Sun, 2010-09-12 at 11:23 -0400, Matthias Clasen wrote:
>
>> > Anyhow, sure, if GTK has no policy that's fine. I assumed it had a
>> > sensible policy...
>>
>> We don't have a written-down policy, beyond 'fit in locally'. But I
>> have become increasingly annoyed by trailing whitespace ...
>
> Can we maybe just use indent?
>

I think mangling all git blame and history is too radical a move,
unless the diff from indent was fairly small. I've needed the blame
history several times just in doing a few gtk patches over the last
couple weeks (I had to figure out why scrolledwindow needed to look at
aux_info for example which went back to 1999 or 2000).

No more _new_ broken whitespace is a good goal to start...

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


Re: rendering-cleanup-next

2010-09-14 Thread Havoc Pennington
+ g_return_if_fail (GTK_WIDGET_ALLOC_NEEDED (widget));

g_return_if_fail( ! GTK_WIDGET_ALLOC_NEEDED (widget));

right?

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


Re: rendering-cleanup-next

2010-09-14 Thread Havoc Pennington
Hi,

On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte  wrote:
> On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen
>  wrote:
>> What about the expose_event  / gtk_widget_send_expose_event stuff ? Do
>> we want to merge what you have first and figure that out afterwards ?
>>
> I want to figure that out afterwards. It's something I haven't figured
> out completely yet. I consider it a part of rendering-cleanup part 4:
> The hackfest menace.
>

The thing about this is someone will have to go git-digging to get
back the deleted docs and stuff. We end up intermediately deleting
expose-event then bringing it back then moving it to WidgetWithWindow
thingy.

I can do it after you merge if you like rather than trying to explain
what I mean in email.

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


Re: rendering-cleanup-next

2010-09-14 Thread Havoc Pennington
Hi,

On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte  wrote:
> I'm actually not sure about that. First, we don't have any code that
> defines if an allocation is valid or even defines what a "valid"
> allocation is. Or do we? gtk_widget_get_allocation() at least doesn't
> do anything there.

yes, we have GTK_WIDGET_ALLOC_NEEDED(). draw() should whine if an
alloc is needed.

I don't think there's much question here. Drawing without an updated
allocation is just a bug, plain and simple.

Widgets need this guarantee. For example if I'm coding GtkLabel, I
should be able to create the PangoLayout in size_allocate and assume
that I have the right layout in draw().
If you don't require updating the allocation, I might draw() some old
text that has been changed.

(Not saying GtkLabel works this way, I didn't look, just that if it
did work this way it would be correct and would have worked in GTK
2.x. And it's certainly easier to write a correct widget if we keep
this invariant.)

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


Re: rendering-cleanup-next

2010-09-13 Thread Havoc Pennington
Hi,

On Mon, Sep 13, 2010 at 4:26 AM, Alexander Larsson  wrote:
> I'm personally a tiny bit uneasy about dropping bg None, as in some
> cases its really required to do flicker-free stuff in X. However, with a
> modern Gtk+ these situations are quite rare, and I don't think any of
> these changes really cause any flicker, since:
>
> 1) In practice almost all non-toplevel GdkWindows in a typical Gtk+ app
> are client-side (i.e. have no corresponding native window). This means
> that mapping them does not make X clear the area to the background, and
> there is no flicker.
>
> 2) Even for windows with native windows there is often no flicker, as
> the X11 gdk backend aggressively set+unsets background None around
> things like moves, resizes, maps and reparents in order to not render
> anything to the screen until we do the expose.

Fair enough. It looked to me like the None still in GTK were all on
scrollable areas (text and tree view, GtkLayout). So if those are just
client-side anyway, None background isn't doing anything.

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


Re: questions re: aux info, size request

2010-09-13 Thread Havoc Pennington
Hi,

On Mon, Sep 13, 2010 at 7:06 AM, Tristan Van Berkom
 wrote:
> Heh, do you mean GtkWindow widgets or GtkWidgets that have their own
> GdkWindow ?

Widgets that have their own GdkWindow

i.e. I was proposing that when adjusting a size request,

if (gtk_widget_get_window(widget))
{
  if (*minimum_size < 1) *minimum_size = 1
}

> I think essentially to allow 0x0 allocations we either need to
> allow GdkWindows to be created at a 0x0 size (currently they
> also force >= 1x1 internally)... or we need to add some special casing
> code to GtkWidget's to handle their GdkWindows with care at
> allocation time (naturally they all just call gdk_window_move_resize()
> unconditionally).

If you force the 1x1 request then in theory you would not ever get a
0x0 allocation, right? But to be sure could also force 1x1 allocation
(which is already done), but change that requirement to only apply if
gtk_widget_get_window() != NULL

I was proposing this approach - window widgets must be 1x1 - because
the alternative is to unmap when receiving a 0x0 allocation.
(HippoCanvas does the unmap thing, in fact 0x0 allocation and unmapped
are the same state in HippoCanvas, iirc.) I think the unmap-on-0x0
will be complicated to apply to GTK and maybe not that useful, since
the goal is to get rid of window widgets, keeping only the ones that
truly conceptually have a GdkWindow - toplevels and embeds - and
requiring toplevels to be 1x1 is actually logical.

Anyway the basic idea is to avoid changing anything too much, just
move the arbitrary 1x1 requirement only to those widgets that really
need it (those that have a GdkWindow)

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


Re: rendering-cleanup-next

2010-09-12 Thread Havoc Pennington
Hi,

On Mon, Sep 13, 2010 at 12:05 AM, John Ralls  wrote:
>> Could also  make it a gdk_x11 api.
>> But maybe a hint that is a no-op on other backends is better.
>
> I'm in favor of keeping platform-specific stuff in platform-specific files 
> and directories, but that's in large part just because I'm a bit compulsive 
> when it comes to code organization.
>

Making it gdk_x11 doesn't keep the platform-specific in
platform-specific files. It would make all files touched by
d3802ca8331ab09fe752407577b12d1525b5d89e now include gdkx.h and an
#ifdef'd call to the gdk_x11 API. So textview, layout, treeview,
viewport would all now have x11-specific code.

The API need not be X specific, though the details depend on how
Windows and Mac work and I don't know them.

/**
* gdk_window_set_clears_background:
* @window: a #GdkWindow
* @value: #TRUE to clear window to its background when damage occurs
*
* If a window is set to clear its background, when a region of the
window needs repainting because the underlying window system has
* discarded the window's pixels, the window system will first clear
the region to the window background
* (see gdk_window_set_background_pattern()) and then GDK will send a
#GdkEventExpose indicating the need to repaint.
*
* If a window is not set to clear its background, the #GdkEventExpose
will be sent but no extra work will be done by the
* window system to update the window's pixels. The first change in
pixels will come from the expose event handler.
*
* Clearing the background may produce a superior visual effect in some
cases, because the window background may be a more appealing
* or less confusing thing to show the user than potentially undefined
pixels or leftover framebuffer contents.  However, in other contexts,
* painting the background creates flicker because the background has
little to do with the final window contents, and it's better
* to leave whatever is onscreen until the actual window contents can be painted.
*
* For expose events generated internally to GDK with
gdk_window_invalidate_region(), the background will never be cleared.
* This is because the purpose of the background clearing is to show
the background in the time between window system
* losing the pixels, and the application repainting. For
application-generated invalidations, the window system is not throwing
* away any pixels so there is no issue.
*
* gdk_window_begin_paint_region() always paints the background, and
GTK+ always uses gdk_window_begin_paint_region()
* around expose event handlers.
* As a result, expose event handlers can assume the background has
been painted, even if the window is set not to
* clear its background.
*
* On window systems that retain window contents, there is no need to
generate expose events in the window system and
* thus gdk_window_set_clears_background() would not do anything.
*
* On window systems that do not support clearing to background, or do
not support clearing to the particular kind of
* background pattern you've set, the background will not be cleared.
As long as you paint using gdk_window_begin_paint_region()
* the final result of your repaint will still be correct, however.
*/


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


Re: padding cleanup

2010-09-12 Thread Havoc Pennington
Hi,

I merged the main patch to master. I wrote docs (see attached) but did
not push them yet because I can't figure out how to actually document
a non-signal virtual function in a non-interface.
What I have here puts the text of the docs in the HTML but it doesn't
look nice. Does gtk-doc just not do this?

Havoc
From 218ab01aa87e9344f6708ae32d74503014508905 Mon Sep 17 00:00:00 2001
From: Havoc Pennington 
Date: Sun, 12 Sep 2010 21:43:39 -0400
Subject: [PATCH] Add documentation on adjust_size_request adjust_size_allocation

Also note in the docs for various other functions, whether they
use adjusted or "parent container" size allocation.
---
 gtk/gtksizerequest.c |   59 ++
 gtk/gtkwidget.c  |   28 ++-
 gtk/gtkwidget.h  |   36 ++
 3 files changed, 121 insertions(+), 2 deletions(-)

diff --git a/gtk/gtksizerequest.c b/gtk/gtksizerequest.c
index 543bbc1..8ae2662 100644
--- a/gtk/gtksizerequest.c
+++ b/gtk/gtksizerequest.c
@@ -87,6 +87,34 @@
  * width. By following this rule any widget that handles height-for-width
  * or width-for-height requests will always be allocated at least
  * enough space to fit its own content.
+ *
+ * Often a widget needs to get its own request during size request or
+ * allocation, for example when computing height it may need to also
+ * compute width, or when deciding how to use an allocation the widget may
+ * need to know its natural size. In these cases, the widget should be
+ * careful to call its virtual methods directly, like this:
+ * 
+ * Widget calling its own size request method.
+ * 
+ *   GTK_SIZE_REQUEST_GET_IFACE(widget)->get_width(GTK_SIZE_REQUEST(widget), &min, &natural);
+ * 
+ * 
+ *
+ * It will not work to use the wrapper functions, such as
+ * gtk_size_request_get_width(), inside your own size request
+ * implementation. These return a request adjusted by #GtkSizeGroup
+ * and by the GtkWidgetClass::adjust_size_request virtual method. If a
+ * widget used the wrappers inside its virtual method implementations,
+ * then the adjustments (such as widget margins) would be applied
+ * twice. GTK+ therefore does not allow this and will warn if you try
+ * to do it.
+ *
+ * Of course if you are getting the size request for
+ * another widget, such as a child of a
+ * container, you must use the wrapper APIs;
+ * otherwise, you would not properly consider widget margins,
+ * #GtkSizeGroup, and so forth.
+ *
  * 
  * 
  */
@@ -423,6 +451,12 @@ gtk_size_request_get_request_mode (GtkSizeRequest *widget)
  * This call is specific to height-for-width
  * requests.
  *
+ * The returned request will be modified by the
+ * GtkWidgetClass::adjust_size_request virtual method and by any
+ * #GtkSizeGroup that have been applied. That is, the returned request
+ * is the one that should be used for layout, not necessarily the one
+ * returned by the widget itself.
+ *
  * Since: 3.0
  */
 void
@@ -445,6 +479,13 @@ gtk_size_request_get_width (GtkSizeRequest *widget,
  *
  * This call is specific to width-for-height requests.
  *
+ * The returned request will be modified by the
+ * GtkWidgetClass::adjust_size_request virtual method and by any
+ * #GtkSizeGroup that have been applied. That is, the returned request
+ * is the one that should be used for layout, not necessarily the one
+ * returned by the widget itself.
+ *
+ *
  * Since: 3.0
  */
 void
@@ -468,6 +509,12 @@ gtk_size_request_get_height (GtkSizeRequest *widget,
  * Retrieves a widget's minimum and natural width if it would be given
  * the specified @height.
  *
+ * The returned request will be modified by the
+ * GtkWidgetClass::adjust_size_request virtual method and by any
+ * #GtkSizeGroup that have been applied. That is, the returned request
+ * is the one that should be used for layout, not necessarily the one
+ * returned by the widget itself.
+ *
  * Since: 3.0
  */
 void
@@ -490,6 +537,12 @@ gtk_size_request_get_width_for_height (GtkSizeRequest *widget,
  * Retrieves a widget's minimum and natural height if it would be given
  * the specified @width.
  *
+ * The returned request will be modified by the
+ * GtkWidgetClass::adjust_size_request virtual method and by any
+ * #GtkSizeGroup that have been applied. That is, the returned request
+ * is the one that should be used for layout, not necessarily the one
+ * returned by the widget itself.
+ *
  * Since: 3.0
  */
 void
@@ -514,6 +567,12 @@ gtk_size_request_get_height_for_width (GtkSizeRequest *widget,
  * This is used to retrieve a suitable size by container widgets which do
  * not impose any restrictions on the child placement.
  *
+ * The returned request will be modified by the
+ * GtkWidgetClass::adjust_size_request virtual method and by any
+ * #GtkSizeGroup that have been applied. That is, the returned request
+ * is the one that should be used for layout, not necessarily the one
+ * returned by the widget i

Re: rendering-cleanup-next

2010-09-12 Thread Havoc Pennington
Hi,

On Sun, Sep 12, 2010 at 5:05 PM, Matthias Clasen
 wrote:
> Also, the idea to separate the translation and the size in
> size_allocate is intriguing.
>

A prior art thing I thought of that's relevant, Clutter has the
translation transform *and* the allocation origin.

The clutter model is that there's a transform (a full matrix, 3D of
course not 2D as in Cairo) which only affects painting (first you do
layout, then you can transform when painting so the actor need not
paint inside its allocation).

I guess the allocation.x,y translation is conceptually part of the
allocation (or part of layout). The thing is that the x,y is only of
interest to the parent layout container, while the width,height is
also of interest to the child. With adjust_size_allocation, though,
child-interesting allocation doesn't really match what the parent
assigned anyhow. So gtk_widget_size_allocate() (assigning allocation)
could take raw allocation including x,y and then the virtual method
(going to child) gets adjusted allocation with no x,y perhaps. The x,y
could be handled with no virtualization i.e. just stored by GtkWidget
rather than storing it in the size_allocate default handler. Widget
implementations could never look at GtkAllocation, only at
get_allocated_width/height (whatever that would be called). Container
implementations would look at GtkAllocation of their children though.

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


Re: padding cleanup

2010-09-12 Thread Havoc Pennington
Hi,

I pushed a widget-padding-2 branch which has everything cleaned up.
Both widget-padding and widget-padding-2 can be deleted once this is
merged.
(I can merge if you like or feel free. or let me know what else to change.)

While messing with branches, I noticed hp-patches and havoc-patches
branches last changed in 2000. I think it's fair to assume I'm not
using these anymore and delete them. :-P

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


Re: padding cleanup

2010-09-12 Thread Havoc Pennington
Hi,

On Sun, Sep 12, 2010 at 6:44 AM, Benjamin Otte  wrote:
> Uh, you've found out about one of my secret projects. Actually, what
> I'm aiming at is reftests (see
> http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html for
> a description). They are independant of font settings, themes etc if
> done right.

Sounds cool!

> A big problem with comparing a rendering to a default image - unless

Yeah, agreed that an automated test where canonical images were
checked into git would probably keep breaking in annoying ways. I do
think it'd be easier than Cairo - or at least, certain tests would be
pretty robust. For example, if you packed various colored rectangles
into GtkHBox with different packing parameters, I don't think that
would have changed its pixels in years - it's not quite like Cairo
where you're doing the complex antialiasing and so forth, and the
exact pixels rendered aren't necessarily defined. If I have an event
box with background color 0xff and I set its size request and pack
it into a GtkBox, then that just can't change unless a GTK API has
changed. Possibly some font - or fake font that's just full of boxes -
could be shipped with GTK to keep text rendering stuff from
interfering.

However the automated tests are done, just having a "toolset" for
rendering out a bunch of useful widget images as PNGs will be awfully
handy. Some use-cases:

* smoke-test a patch. if I mess with GDK or cairo or size requesting,
if I could build and render a set of "before" images on my machine
locally, and also a set of "after" images, and quickly do an automated
diff - there's no "pixman changed" or "font changed" issues since it's
all on my machine, no canonical images located in git - I could see if
I triggered any g_warning() or changed how anything paints, without
having to manually walk through gtk-demo/testgtk and look for broken
stuff, which is what I've been doing

* quick-check a theme. sort of like metacity-theme-viewer which shows
windows in a bunch of states

* write git-bisect scripts. for example it probably would have been
worthwhile to automate bisecting that bug we just bisected, by writing
a little "git bisect run" program to render the good and bad
insensitive label.

Anyway however it works, clearly your draw() work is going to enable
it, and this has got to be a giant win from that work.

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


Re: questions re: aux info, size request

2010-09-12 Thread Havoc Pennington
Hi,

On Sun, Sep 12, 2010 at 1:33 AM, Tristan Van Berkom
 wrote:
> Ok I see, so we end up with:
>  - set_size_request() Can be used to increase the minimum request

I was thinking this should stay backward compatible and allow lowering
it, fwiw. Though I can't actually come up with a use case, I'm just
being paranoid.

btw - have you looked into allowing 0x0 allocations at all? (at 0x0,
draw() would not be called, I think, so draw() implementations would
not have to handle 0x0; also, 0x0 would not really work on window
widgets, but this could be addressed by forcing window widgets to have
at least a 1x1 minimum size. i.e. replace 1x1 min allocation with a
1x1 min request for window widgets only)

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


Re: questions re: aux info, size request

2010-09-11 Thread Havoc Pennington
Hi,

On Sun, Sep 12, 2010 at 12:45 AM, Tristan Van Berkom
 wrote:
> While on this topic, there's this XXX comment I left dangling
> in gtksizegroup.c:
>   http://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n677
>
> I was thinking maybe that for all the widgets in a group to be
> effectively the same size, maybe we should be basing the minimum
> base requests from the natural requests of all widgets in a group.

I would expect that GtkSizeGroup caused all widgets in the group to
request a min size of the largest min size in the group, and a natural
size of the largest natural size in the group. Then it Just Works,
right? Is there a reason that only one of min or natural can be picked
for size group?

> But if set_size_request() were to limit the natural size; combining
> it with sizegroups that demand/require the natural size as a minimum
> might work nicely.

To be clear, I was proposing a set_natural_size() or something (i.e. I
think making set_size_request set natural would be too incompatible)

It might be clearer to rename set_size_request to set_minimum_size()
but that function is maybe too heavily used to rename... at least
without keeping the old name also.

btw along these lines, I can't remember if I filed the attached patch.
Natural size much less useful without it.

Havoc
From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001
From: Havoc Pennington 
Date: Mon, 6 Sep 2010 11:18:35 -0400
Subject: [PATCH] Make GtkWindow default to natural size not minimum size

Otherwise your ellipsized labels all start out ellipsized, unless
you manually gtk_window_set_default_size().

This probably makes it important to clamp the window's default
size to the size of the monitor's work area.
---
 gtk/gtkwindow.c |4 ++--
 tests/testgtk.c |1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/gtk/gtkwindow.c b/gtk/gtkwindow.c
index 5f75dae..b50a9ab 100644
--- a/gtk/gtkwindow.c
+++ b/gtk/gtkwindow.c
@@ -5725,9 +5725,9 @@ gtk_window_compute_configure_request_size (GtkWindow *window,
   
   if (window->need_default_size)
 {
-  gtk_widget_get_child_requisition (widget, &requisition);
+  gtk_size_request_get_size (GTK_SIZE_REQUEST (widget), NULL, &requisition);
 
-  /* Default to requisition */
+  /* Default to natural requisition */
   *width = requisition.width;
   *height = requisition.height;
 
diff --git a/tests/testgtk.c b/tests/testgtk.c
index cddb7df..8ea1117 100644
--- a/tests/testgtk.c
+++ b/tests/testgtk.c
@@ -8431,6 +8431,7 @@ create_window_sizing (GtkWidget *widget)
 			 gtk_widget_get_screen (widget));
   label = gtk_label_new (NULL);
   gtk_label_set_markup (GTK_LABEL (label), "Window being resized\nBlah blah blah blah\nblah blah blah\nblah blah blah blah blah");
+  gtk_label_set_ellipsize (GTK_LABEL (label), PANGO_ELLIPSIZE_END);
   gtk_container_add (GTK_CONTAINER (target_window), label);
   gtk_widget_show (label);
   
-- 
1.7.0.4

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


Re: padding cleanup

2010-09-11 Thread Havoc Pennington
Something that occurred to me mid-bisect is that with Benjamin's
draw() work, it would probably be straightforward to write the
following test program:

* instantiate every widget type in GTK (or even various modes of every
widget type, like different text styles, wrap or not, padding/border
or not, etc.)
* dump a giant directory of PNGs representing the paint of every one
of those in every GtkStateType

This is already useful because it can be manually inspected and used
for example to verify that a theme engine works.

But then a natural extension is that you could write a "PNG cmp" tool
(load two PNG, compare pixels). Then dump widget renders before, dump
widget renders after, compare.

If you could control for environmental issues (fonts, font settings)
you could have an automated test that 1) ensured the allocate/draw
codepath didn't crash or spew debug spam for any widget in GTK (use
G_DEBUG=fatal_warnings), and 2) got upset if anything changed about
how widgets are rendered. If you changed rendering on purpose, you'd
just regen the canonical images.

You could even easily test layout algorithms (just render various box
packings). And automate testing of widget properties by having handy
routines that set every possible enum value of a prop, for example,
rendering them all.

Seems like a really simple way to get _huge_ test coverage. I guess it
was possible already by starting an Xvfb (which you'd have to do
anyhow) and taking screenshots... but that might have been slow and/or
racy, I don't know.

Well, a project for a rainy day. It would have caught this little buglet ;-)

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


Re: padding cleanup

2010-09-11 Thread Havoc Pennington
Hi,

On Sat, Sep 11, 2010 at 11:41 PM, Matthias Clasen
 wrote:
> Turns out this is unrelated to your branch. I've bisected this to
>

Oops, I just burnt a hole in my lap bisecting this too. At least _one_
of those checkouts could have managed not to rebuild the whole tree...

I got to this commit though, one after yours, as the guilty one (for
me ccacd3a was OK)

commit 709e05cdb20fd6d2360b7158286d6c3176c300c0
Author: Benjamin Otte 
Date:   Sat Aug 7 02:18:06 2010 +0200

style: Use _gtk_pango_fill_layout()


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


Re: padding cleanup

2010-09-11 Thread Havoc Pennington
Hi,

I pushed the changes I had in mind to the widget-padding branch. I
have a rebased/squashed branch cleaned up for merging, too, if anyone
wants me to push or send that version.

the changes are:

733991c84df4300ec54af8b557385759a93360f0 Rename GtkWidget padding to margin
83008588e162b78f8f66ba371c3691a2ca759f3b Use gint16 for GtkBorder
cbfbe68eca5835f8b0151ca77f01ab8b370c50d8 Adapt to widget->allocation
becoming private
dd3f8cefeb386a34b170b200705dc482435efa84 Just use GtkBorder for
padding in GtkAuxInfo

If I forgot something we talked about let me know. Otherwise I think
this could be merged to master or given a final review.

I guess a pending task is to use
gtk_container_class_handle_border_width() more, and/or add a GtkMisc
equivalent, but not sure we need to block on that.

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


Re: questions re: aux info, size request

2010-09-11 Thread Havoc Pennington
Hi,

Just thinking, in the new GtkSizeRequest world it's probably more
useful to set natural size than minimum size.

With Clutter, what we often find ourselves wanting to do at litl is
"set natural size, clamping it to be larger than minimum size"

So for example setting natural size to 0 would mean "set natural size
equal to minimum size"

Setting natural width to 100 would be "100, or as small as possible
without breaking the widget"

This would provide the "set a size manually, but don't break the
widget" functionality.

Anyhow: it would be a shame to ship the "ignore set size request
smaller than min size" by accident. Should I open a bug? Or should I
change (and document) set_size_request to "increase only"?

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


Re: rendering-cleanup-next

2010-09-11 Thread Havoc Pennington
Hi,

On Sat, Sep 11, 2010 at 11:46 AM, Havoc Pennington  wrote:
> * size_allocate vfunc and wrapper change to (* size_allocate)
> (GtkWidget, int w, int h)
>

Another possible addition here, which is in both Clutter and
HippoCanvas, would be an ORIGIN_CHANGED flag. (Clutter uses a flags
arg, Hippo uses just a boolean.)

One purpose of this flag is that window widgets need to know when the
absolute origin changes. This allows them to keep the window
positioned properly. You would need this to remove knowledge of
windows from the GtkWidget/GtkContainer/GtkSizeRequest/GtkSizeGroup
"core" and confine such knowledge to certain GtkWidgetWithWindow
classes that had to keep the GdkWindow positioned themselves. (While
right now the GTK core takes care of that.)

A related cleanup would be to make the widget translation always be
with respect to the parent container, rather than with respect to the
nearest GdkWindow.

At that point you could traverse widgets for most purposes without
caring whether they had a window.

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


Re: rendering-cleanup-next

2010-09-11 Thread Havoc Pennington
Hi,

On Sat, Sep 11, 2010 at 12:57 PM, Benjamin Otte  wrote:
> Ugh, I'd always assume that widget.get_width() would give me the width
> of the widget, not the width the widget thought would be ideal but had
> nothing to do with reality. Also, a width getter would never return 2
> values for me.
> Should we maybe rename it to gtk_size_request_get_natural/minimum_width()?
> Tristan?

You really want a single method to do natural and minimum, or else
it's really annoying for implementors (the methods share too much
code).

If going this road, maybe go for consistency with Clutter: call it
get_preferred_width(). In earlier GTK patches it was
get_desired_width(). May as well match Clutter though right?

The problem with having a get_width() that returns allocation is that
widgets don't have to have an allocation. Either they've never been
allocated at all, or it's out of date. In both those cases, the
request is closer to reality.

I guess that's why Clutter's get_width() returns allocation if updated
and request otherwise ;-)

btw if there's a get_allocated_width() (or whatever it's called), it'd
be nice to put in:

if (widget needs allocation)
 {
   g_warning("get_allocated_width() called on a widget that has not
yet been allocated. Widgets are only guaranteed to be allocated inside
draw() or if you have just allocated them yourself.");
  }

Also, the gtk_widget_draw() wrapper could usefully have:

 if (widget needs allocation)
   g_warning("widget must have up-to-date allocation in order to draw it");

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


Re: rendering-cleanup-next

2010-09-11 Thread Havoc Pennington
Hi,

On Sat, Sep 11, 2010 at 1:50 PM, Benjamin Otte  wrote:
> The problem here is that I want to get rid of proxying the ugly X11
> background API via GDK. Neither Windows nor Quartz have anything
> similar. So my approach was to use a cairo_pattern_t in the API and
> then say "The backends are responsible for mapping it to the system
> backgrounds as well as possible." as we overpaint it during exposes
> anyway. So hat we do in the gdk_x11_window_set_background() call is
> open for debate.

Does GDK have enough information to know when to set background to None?
The patch
d3802ca Remove calls that try to set GDK_NO_BG

basically removes hints to GDK that the background should not be
repainted by the OS. I don't know how GDK would know this.

I don't know exactly what the API should be. Maybe set_hint_no_clear()
or set_autopaint() or whatever it is. The main thing is, I think pre-
this patch, things probably did not flicker as much, and post- this
patch, they are probably flickery and uglier. So that's a user-visible
regression. It just doesn't seem like a good idea to me to regress
that.

The API for this may be something that's a no-op on Windows and/or
Mac, I don't know.

I don't really know the right API, but regressing the user-visible
would suck, that's the .02 here.

I would have to dig into more details to say "here is exactly what
would look uglier and how" but I'm just assuming the existing "set
background to None" calls had some purpose.

> First of all, expose events are already different from all other
> events today in GTK2. One of them is sent via
> gtk_widget_send_expose(), the other via gtk_widget_send_event().

But send_expose() was only required because no-window widgets get
exposes ... but with your patch they no longer need to.

In GTK 1.2, iirc, expose-event was the raw GdkWindow event and there
was a draw() signal. In 2.0, we consolidated on expose-event and
generated expose-event for no-window widgets. With 3.0 and your patch,
what would make sense to me is to make expose-event again be just the
raw window system event, and no-window widgets therefore never get
expose-event. send_expose() would not be needed because expose-event
would have zero pre-processing; the pre-processing would all be in
front of draw(), not in front of expose-event.  expose-event becomes
just the raw thing from GdkWindow. Back to the future!

> Also, I do think that having two events (draw and expose-event) on
> GtkWidget is confusing, in particular because one of them is only
> emitted sometimes (gtk_container_propagate_draw() would not cause
> expose events).

To be clear, I'm talking about making expose-event show up in _less_
of the code.

I would say, expose-event should be defined to be exactly what comes
from GdkWindow, no pre-processing or special handling _at all_, and it
only happens on window widgets. In the GTK of the future, this
expose-event thing would be like the other obscure list of events that
only window widgets ever get (destroy-notify, visibility-notify, blah
blah). These events should all be lifted up out of GtkWidget somehow
and only be present on windowed widgets; maybe via an interface, I
don't know.

A subset of events that are actually of interest to no-window widgets
would then need to go to all widgets - motion events, a few others.
Possibly the actual event struct even differs.

What would be super-clean would be that all dealing with GdkWindow
events (and GdkWindow in general) lives walled off in a
GtkWidgetWithWindow class. GtkWidget itself should not have any such
knowledge.

Anyhow so where I'm coming from on this, is that it then makes sense
to start moving all the event handling stuff into GtkWidget, in the
event-handling methods. But taking events out of the GtkWidget API,
and taking them out of code that applies generically to all widgets in
gtkmain.c etc. This is all in preparation for then taking most of the
event vfuncs and signals and copying them out of GtkWidget and into
some sort of GtkWidgetWithWindow.

Specifically looking at the patch, first the code in
http://git.gnome.org/browse/gtk+/tree/gtk/gtkmain.c?h=rendering-cleanup-next#n1674
i.e. GDK_EXPOSE switch case in gtkmain.c, this could just be in
GtkWidget (to be later lifted into the GtkWidgetWithWindow thing).

Then looking at gtk_widget_send_expose(),
http://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?h=rendering-cleanup-next#n4863

I think this should not ever work on no-window widgets at all;
no-window widgets can't get an expose, because expose-event is a
GdkWindow thing. So given that it doesn't work on no-window widgets,
make it the expose-event default handler. And then when the
expose-event vfunc and signal are lifted up and out into
GtkWidgetWithWindow, this thing comes with it.

Why not just delete gtk_widget_send_expose(). No reason for GTK 3 to
have that function I don't think.

> What I want to have is a GdkWindow::event signal instead of the magic
> gdk_window_set_user_data() function. Then

Re: rendering-cleanup-next

2010-09-11 Thread Havoc Pennington
Hi,

On Sat, Sep 11, 2010 at 1:11 PM, Benjamin Otte  wrote:
> This is actually a rather ugly situation right now: Everything in the
> widget but the draw function (key press events etc) uses coordinates
> relative to the GdkWindow, only the draw function doesn't. So when
> calling internal get_offsets() style APIs, the draw function always
> has to subtract the allocation again.
>

Oh I see, got it.

Seems like the same basic issue as size_allocate taking the x,y. The
big picture goal would be to make widgets always use self-relative
coordinates.

If there were a facility to get events without having a GdkWindow, it
ought to be designed to go ahead and translate the stuff in the events
relative to the widget.
I had a proposal for that here btw:
http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00223.html

Anyway, certainly ought to land the new rendering branch first. It's
so tantalizingly within reach to have the clipping, scrolling,
event-getting without windows, plus "all coords are widget-relative"
though. Hoping it makes 3.0!

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


Re: rendering-cleanup-next

2010-09-11 Thread Havoc Pennington
Hi,

On Sat, Sep 11, 2010 at 12:57 PM, Benjamin Otte  wrote:
> gtk_paint_*() does - at least in my branch - draw relative to the
> passed in cairo_t. As almost all the paint functions take
> x,y,width,height anyway it doesn't really matter where the origin of
> the cairo_t is. You'll notice in all the "Port to draw vfunc" patches
> that I removed allocation.x/y from the x/y parameters.
> The original paint functions that took a GdkWindow were
> window-relative so had to take into account allocation.x/y.

I'm looking at gtk_scale_draw for example on your branch
http://git.gnome.org/browse/gtk+/tree/gtk/gtkscale.c?h=rendering-cleanup-next#n1159

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


Re: rendering-cleanup-next

2010-09-11 Thread Havoc Pennington
Hi,

On Sat, Sep 11, 2010 at 12:15 PM, Benjamin Otte  wrote:
> What's you opinion on having gtk_widget_get_width() and
> gtk_widget_get_height() functions? They would just return
> widget->priv->allocation.width/height for now.
>
> Such functions would address your issues and would make writing draw
> functions pretty much as simple as they are now, without having to
> pass width and height. And in particular, they'd get rid of the need
> to think about allocations.
> Or would that be a too prominent API?
>

Yep, I was thinking/assuming there would be exactly this. The only
thing I'd add, I think they ought to be named something with
"allocated" in there, for a couple reasons:

- in many languages GtkSizeRequest::get_width() is already just
callable as widget.get_width()
- plain get_width() more naturally gets request, anyhow

Clutter has a hack where get_width() returns the allocation if valid
else the request, but this was a back compat hack / an attempt to be
nice to naive users who don't want to think about request vs.
allocation.

The obvious API might be: get_allocated_width(),
get_allocated_height(), get_allocated_size(); or even change
get_allocation() to return width,height and add separate
get_translation().

Something I just noticed, it looks like widgets are doing
get_allocation and looking at allocation.x,y still because gtk_paint_*
seems to assume that the cairo_t is not translated?
I guess the natural new way for this to work would be for gtk_paint to
pass the theme engine a cairo_t already translated and clipped to the
box the theme element is supposed to be inside. Maybe the new theme
branch has something more radical though.

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


Re: rendering-cleanup-next

2010-09-11 Thread Havoc Pennington
Hi,

On Sat, Sep 11, 2010 at 11:16 AM, Havoc Pennington  wrote:
> I still think passing width, height to draw() is weird.

btw, I guess the argument here (per IRC) is that people might be
confused by allocation.x,y. But this is a really weak band-aid fix for
that, which will be wrong in the long term.

The solution to allocation x,y is to set the larger goal: widgets
don't know their transform (currently GTK only supports translation
transforms, of course). Widgets should always work in a self-relative
coordinate system, on the rare weird occasion where they don't, they
can use gtk_widget_translate_coordinates() which eventually could even
support rotation and scaling, or there could be a flavor that gives
you a matrix.

The actual bug is that widget_size_allocate() receives an x,y and
gtk_widget_get_allocation() gets an x,y. That's where the bug should
be fixed, not by adding some confusing stuff to draw().

It would take some thought to fix the leakage of x,y on the allocation
side, but I think that thought is what's needed, rather than band-aid
pseudo-solutions in draw().

Roughly, the solution could be that:

* size_allocate vfunc and wrapper change to (* size_allocate)
(GtkWidget, int w, int h)

* add gtk_widget_set_translation(widget,x,y)/get_translation()

* containers now have to call
gtk_widget_allocate_and_translate(widget, rectangle) convenience
function instead of size_allocate(). This convenience function
obviously calls size_allocate(rect.w, rect.h) and
set_translation(rect.x, rect.y)

This is a pretty breaking change, but porting apps is no harder than
changing expose-event to draw.

If you want to then be really sick and twisted, once you clear out
GdkWindow you can support a full cairo_matrix_t instead of just
translation... which would be logical and straightforward now that
you've kicked the translation out of the allocation.

Another possible solution is to keep the width,height to draw(), but
_get rid of size allocate_; widgets would then be supposed to support
any width,height at any time being passed to draw(), and they'd in
practice always have to cache their last layout for performance, most
likely. (they'd sort of make the first part of draw() do what they do
now in size_allocate(), iff the allocation has changed, and cache the
result). I don't think this is a very nice solution because it makes
draw() methods multi-purpose and clunky. I think it's cleaner to have
separate vfuncs for doing the layout and handling a paint on the
layout, as GTK already has.

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


Re: rendering-cleanup-next

2010-09-11 Thread Havoc Pennington
Awesome! Some stuff I noticed looking through the branch:

*

A round of rebase/squash might be nice which would make it easier to
review, for example c5c08bafb94e794a88ef5d650999f46b419429ed could
squish into 9badb81a7ed62af1cdf11eb31c7e94293a683429 (I was pretty
confused by the None there at first)

*

I'm skeptical of removing ability to set window background to None.
This feature can be important to avoid visual artifacts on X11. The
API should maybe change to not involve a "NULL" pixmap; conceptually,
what this means is "window system should not auto-clear or auto-paint
the background on exposes" - I don't know if any other platform has
the concept. A new API could be
gdk_window_set_paint_background(gboolean) rather than set_pixmap(NULL)

I think d3802ca "Remove calls that try to set GDK_NO_BG on their
windows" probably results in some things being more ugly.
(flashing/flicker)

This almost goes away as an issue if dropping all subwindows, but I
think setting None on toplevels will still be important sometimes. I
guess in future-composited-desktop-world this also fades in importance
but I'm not sure on when/whether/details.

Anyway - the commit message "undefined behavior is not a good idea"
seems like you're missing the point of this - the idea is not to leave
the window bg undefined, it's to wait and let the app repaint it,
instead of first having window system repaint then the app repaints
(which inherently flickers).

*

I think it would be nicer than send_expose, if you kept expose_event,
but had gtk_widget_real_expose_event() do the GDK_EXPOSE case from
gtk_main_do_event() and then also have the code in send_expose(). i.e.
the default handler for expose_event should set things up and call
draw().

It seems to me kind of bizarre to treat expose events differently from
the others. Right now all GdkWindow events are on Widget. I would
think what makes sense is to keep them all there, until widget->window
becomes optional, and then move them all to some sort of
GtkWidgetWithWindow iface where widgets that subscribe to a
GdkWindow's events would get these but not widgets in general.

The way you have it here, there's no way for people to customize the
raw event handling. Say for example I'm doing a GL-based widget, or
who knows what other weird thing, maybe my app uses Skia, maybe I want
to get the raw expose event. If that makes sense for the app and I
don't need draw-to-pdf, I should be able to do it. Maybe I have a
legacy app that has a pile of Xlib drawing code.

An alternative, which I think is hackier, would be to make
gtk_cairo_get_event() public.

Anyway the ultimate goal would be for only toplevel GtkWindow plus
wonky widgets (GL, embeds) to have the event signals. But whichever
widgets keep the event signals, should still have the expose signal,
imo.

*

I still think passing width, height to draw() is weird. If I were just
reading this API, I would *strongly* tend to guess that it was the
damage rectangle or else the size I'm supposed to paint to, but it
isn't. It's a redundant copy of allocation size. Plus, you're clipping
to allocation _anyway_ so in most cases I don't even _need_ the
allocation size. So the width/height here are just _extra_ typing, not
saving me typing allocation.width,height. App developers basically
_should_ ignore these. So why are they here?

These parameters just confuse and raise questions. If they are defined
to be allocation.width,height, they should not exist. App devs are
going to think "OK, it can't be that" and think it has to be damage
region, or think they are supposed to support drawing to an arbitrary
size, or otherwise try to rationalize the existence of these pointless
redundant parameters. But they don't have a rationale ;-) Things with
no point are confusing. Gratuitous cognitive load.

If I need to know the allocation, then I'll look at the allocation.

*

There's a fair bit of trailing whitespace in the patch. Maybe turn on
trailing-whitespace-highlighting in your editor.

*

Shouldn't gtk_widget_is_drawable() just die? It seems to me the draw()
method can be called when not mapped or visible. In fact it can be
useful to do that if you're trying to render offscreen or to pdf.
(Maybe we want to pedantically require visible, but I don't think we
should have to be mapped, which implies in a toplevel window system
window.)

gtk_widget_draw() is documented as requiring the widget to be
drawable, but I don't see why draw() in its current form needs widgets
to be mapped.


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


Re: Minutes of the GTK team meeting - 2010-09-07

2010-09-07 Thread Havoc Pennington
Hi,

On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi  wrote:
> - branches for alignment and margin for review

widget-padding and widget-expand branches pushed, widget-expand
includes widget-padding

Pending changes not in the branches yet include:
- rename padding to margin
- some docs tweaks Matthias mentioned
- patch all layout containers to handle expand
- patch GtkWindow to auto-set resizability

If you build the branches you can run tests/testadjustsize and tests/testexpand

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


Re: Minutes of the GTK team meeting - 2010-09-07

2010-09-07 Thread Havoc Pennington
Hi,

On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi  wrote:
> - possible addition pre-3.0: surface ↔ pixbuf conversion functions in gdk
>

Incidentally, these should probably be in gdk-pixbuf (to avoid cairo
dep they could just go to guint8*). The main use I guess is say in
Clutter or other cairo-but-not-GdkDrawable contexts.

btw, I think the patch on
https://bugzilla.gnome.org/show_bug.cgi?id=491507 provides the proper
API that we'd also want if cairo adds support for "classic pixbuf"
format. The patch on the bug is having to keep a surface for cairo
format, and a manual byte buffer for old pixbuf format. But if cairo
had old pixbuf format, you'd just keep a surface, period, done. Either
way I think you want new_from_cairo_surface(), get_cairo_surface(),
and you want to do the deprecations of get_pixels(), GdkColorspace,
and related stuff.

I'd say a great path would be to put in the patch on 491507 - possibly
in "max compatibility" mode, i.e. always keep the pixel buffer around
and just pay the memory cost - and then when new cairo comes out, you
could 100% compatibly drop the pixel buffer and have *only* a cairo
surface representation.

If cairo does not add classic pixbuf format (I'm still not sure it
should), then things are trickier, because with my patch on 491507 you
have to choose between definitely 100% compatible but uses 2x memory
until all apps stop calling get_pixels() and new_with_data() and
new(), or 98% compatible but avoids 2x memory sooner.

Still, assuming a cairo dependency is OK, I think the API (and the
deprecations) in this patch are right. The implementation depends a
bit on how picky we want to be about breaking apps in super obscure
cases, and what cairo ends up doing.

If a cairo dependency is not ok, then just simple
convert-to-from-guint8-in-cairo-format is one option, or my original
patch, 
http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00022.html,
is a kind of middle ground between "just add a very raw pixel convert
function" and "swap internal pixbuf representation to cairo" - some
advantages of that original patch include:

- no cairo dependency
- Loader could then grow a property for the desired format, and apps
could opt in to load in cairo format
- if/when a cairo dep was added and cairo had "classic pixbuf" format,
pixbuf could be transparently switched to keep a cairo surface
internally

The disadvantages vs. the patch attached to
https://bugzilla.gnome.org/show_bug.cgi?id=491507 might include:

- does not automatically convert any existing pixbufs without changing apps
- does not cache a cairo surface on each pixbuf,  gdk continues to
convert on each paint
- does not deprecate get_pixels() (since there's no cairo surface to
use instead)
- can't draw to the pixbuf with cairo (until cairo supports pixbuf format)

Overall I think adding new_from_cairo_surface(), get_cairo_surface(),
and deprecating get_pixels/new_from_data/&friends, is the right thing
to do, whether or not cairo gets classic pixbuf format. And the patch
is pretty much ready. (and tunable for desired compatibility vs.
efficiency tradeoff) But I do understand if people don't have time to
dig in for 3.0.

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


Re: questions re: aux info, size request

2010-09-07 Thread Havoc Pennington
Hi,

On Tue, Sep 7, 2010 at 3:49 AM, Tristan Van Berkom
 wrote:
> What is the use-case for forcing a widget to request something smaller
> than it's content ?
>

I think the use-cases are mostly caused by the old limited layout
system. For example, to get a label to ellipsize, you used to have to
set its size request to something small and then pack it with
expand=true.

I'd say the semantics of set_size_request should be "pretend the
widget's size request vfuncs returned what set_size_request set" so
size groups and widget padding would still potentially grow that size
request.

It is just a back compat API though really; I'm not sure what it's
really good for. The "only increase what vfuncs return" behavior does
seem more useful in at least one case, where you just want to be sure
the min size is at least something-or-other, but are willing to use a
larger value if the true min size is larger.

I guess some searching through apps to see how they use it might be
instructive. (Is there an easy way to search through code for lots of
gtk apps?)

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


Re: padding cleanup

2010-09-07 Thread Havoc Pennington
Cool. So I'm inclined to search-and-replace the patch and make the properties:

margin-left
margin-right
margin-top
margin-bottom
margin   /* sets all four at once */

I'll give it a couple more days though in case this turns out to be
controversial so I don't do too much busywork ;-)

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


Re: gtk_container_new_child (was Re: Wrapping Box Container)

2010-09-06 Thread Havoc Pennington
I forgot that GtkWidget::parent already works:

g_object_new (TYPE_FOO, "parent", box, "blah", 42, NULL)

This is a pretty nice solution I think. You don't even have to save a
pointer to the new object if you aren't doing anything other than
adding it to parent and setting a couple of props.

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


Re: magic expand flag on GtkWidget

2010-09-06 Thread Havoc Pennington
Hi,

On Mon, Sep 6, 2010 at 8:18 PM, Matthias Clasen
 wrote:
> In particular the automatic window resizability will be nice.

Unfortunately this part is scary ;-) a whole lot of the gtkwindow.c
code related to this was last touched by me in 2001, some was last
touched even earlier than that, and I remember having to revise my
rewrite of this code many many times to handle all the corner cases.
But maybe this feature is relatively superficial and won't interact
with the scary stuff, right? ...

But yeah, this is kind of the cool part. At the same time we can fix
gtkwindow to take advantage of natural size to set default size, and I
think in order to do that, we need to constrain the default size to
the monitor work area.

> I do foresee some complications in the expand-propagation for more
> complicated containers, though:
>
> - Just because a tab label expands, the notebook should probably not.
>
> - a table/grid can only expand vertically if it has an entire row of
> vertically expanding children (I think ?)
>

Right. I think the containers should be able to fix this stuff in
their compute_expand.

Also, for similar cases an app may have, they can set an explicit
expand=FALSE on a container and expansion will not propagate upward
any further.

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


legacy-free grid container

2010-09-06 Thread Havoc Pennington
With
https://bugzilla.gnome.org/show_bug.cgi?id=628828
and
https://bugzilla.gnome.org/show_bug.cgi?id=628902

Box and Table are pretty much all messed-up. They have a bunch of
redundant flags to specify, and their redundant fill flag is a problem
because it has the wrong default (must always be true to make the
widget flags work).

Rather than churn up Box and Table in-place, maybe it would be nicer
to create a legacy-free new GtkGrid.

The basic idea of GtkGrid is:

* it just puts things in rows and columns, and implements homogeneity;
expand, fill, padding are now all in Widget
* it is an infinite grid, not a fixed size at construct time like
GtkTable. so you don't have to keep construct size in sync with what
you add. It auto-resizes to hold stuff.
* the coordinate system goes into negative numbers, so you can add
things on either side of the axes
* its "default" mode if you just container_add() is like a box, in
that it just keeps appending children to the axis. they are then in a
single-row or column table. this lets it replace Box.
* but you can also do an add_at(grid, child, x, y, cells_wide,
cells_high) (note, coords then WxH in cells, rather than annoying
"attach points" where you have to change both numbers to move)
* you could also do add_by(grid, existing_child, child,
side_of_existing_child, cells_wide, cells_high) which lets you build
things up relatively. this is nice because if you want a stack of
stuff above the foobar, and you insert something before the foobar,
you don't have to go and redo all your coordinates
* have separate "h" and "v" homogeneous flags to force all rows or all
columns to be the same height
* have separate "h" and "v" spacing which would be the same between
all rows or all columns
* minor thing: kill SHRINK mode in table, it's broken (esp. in a world
with min size separate from natural)
* an issue: the naming of the cell-based access (x,y) is a mess if you
allow it to be GtkOrientable like box. but if you require an
add_on_axis(orientation, child) then it's not as convenient as box.

Anyway something like that. It's just a box if you create and
container_add(), but it can become a table if you just start packing
things off the main axis (no more "box regret" - "I wish I'd used a
table now that I'm halfway into this!"). And it lacks the redundant
padding, expand, fill confusion when mixed with the new patches.

Probably there are better plans but that's the one I thought of.

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


magic expand flag on GtkWidget

2010-09-06 Thread Havoc Pennington
Hi,

This is a major enough change it should probably hit the list and not
just bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=628902

The patch needs finishing as noted in the bug but you can already play
with it, it just is missing some production details.

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


combo/option (was Re: [REMINDER] GTK+ Team Meeting, 2010-09-07)

2010-09-06 Thread Havoc Pennington
Hi,

On Mon, Sep 6, 2010 at 10:06 AM, Emmanuele Bassi  wrote:
>>  ‣ undo combobox / option menu mix ?

what is the argument on this? sounds like going in circles ;-)

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


Re: padding cleanup

2010-09-05 Thread Havoc Pennington
https://bugzilla.gnome.org/show_bug.cgi?id=628828
has a patch ready for review.

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


Re: questions re: aux info, size request

2010-09-04 Thread Havoc Pennington
Bugzilla is down, so here's a patch for another problem

Havoc
From d8b6eb473b0eb13b9540f91516f2f60df2d5f1a7 Mon Sep 17 00:00:00 2001
From: Havoc Pennington 
Date: Sun, 5 Sep 2010 01:42:14 -0400
Subject: [PATCH] default impls of width_for_height,hfw should chain directly not use wrapper API

In GtkBin and GtkWidget we tried to provide handy defaults that
call get_width if there's no get_width_for_height and
get_height for get_height_for_width.

However, they used the wrapper API on GtkSizeRequest instead of
chaining directly to the other method implementation.

This could result in all kinds of surprising behavior, for example,
get_width_for_height() would now already include the effects of set_size_request().

If nothing else it's inefficient. But it's just conceptually wrong,
because to chain to another implementation, we should call the other
implementation, not call a wrapper around the other implementation
(when we're already inside a previous invocation of the wrapper,
i.e. compute_size_for_orientation() ends up reinvoking itself
in the same orientation on the same object which it pretty
likely isn't intending to do)
---
 gtk/gtkbin.c|   11 ---
 gtk/gtkwidget.c |6 +++---
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/gtk/gtkbin.c b/gtk/gtkbin.c
index ecc2b99..b550009 100644
--- a/gtk/gtkbin.c
+++ b/gtk/gtkbin.c
@@ -214,10 +214,15 @@ get_child_padding_delta (GtkBin *bin,
 			 gint   *delta_v)
 {
   GtkBinPrivate *priv = bin->priv;
-  gint hmin, vmin, child_hmin, child_vmin;
+  gint hmin, vmin, hnat, vnat, child_hmin, child_vmin;
 
-  gtk_size_request_get_width (GTK_SIZE_REQUEST (bin), &hmin, NULL);
-  gtk_size_request_get_height (GTK_SIZE_REQUEST (bin), &vmin, NULL);
+  /* we can't use gtk_size_request_get_width() wrapper because we want
+   * our "original" request, not any external adjustments from
+   * set_size_request() or whatever.  we have to ask for natural also
+   * because NULL isn't allowed for the direct vfuncs
+   */
+  GTK_SIZE_REQUEST_GET_IFACE (bin)->get_width(GTK_SIZE_REQUEST (bin), &hmin, &hnat);
+  GTK_SIZE_REQUEST_GET_IFACE (bin)->get_height (GTK_SIZE_REQUEST (bin), &vmin, &vnat);
 
   gtk_size_request_get_width (GTK_SIZE_REQUEST (priv->child), &child_hmin, NULL);
   gtk_size_request_get_height (GTK_SIZE_REQUEST (priv->child), &child_vmin, NULL);
diff --git a/gtk/gtkwidget.c b/gtk/gtkwidget.c
index 20ddbbf..95ad36f 100644
--- a/gtk/gtkwidget.c
+++ b/gtk/gtkwidget.c
@@ -10927,7 +10927,7 @@ gtk_widget_real_get_height_for_width (GtkSizeRequest *layout,
   gint  *minimum_height,
   gint  *natural_height)
 {
-  gtk_size_request_get_height (layout, minimum_height, natural_height);
+  GTK_SIZE_REQUEST_GET_IFACE (layout)->get_height(layout, minimum_height, natural_height);
 }
 
 static void
@@ -10935,8 +10935,8 @@ gtk_widget_real_get_width_for_height (GtkSizeRequest *layout,
   gint   height,
   gint  *minimum_width,
   gint  *natural_width)
-{ 
-  gtk_size_request_get_width (layout, minimum_width, natural_width);
+{
+  GTK_SIZE_REQUEST_GET_IFACE (layout)->get_width(layout, minimum_width, natural_width);
 }
 
 static void
-- 
1.7.0.4

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


Re: questions re: aux info, size request

2010-09-04 Thread Havoc Pennington
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


  1   2   3   4   >