[...]
> fact by the threading system ? [ I was never persuaded that glib's
> demand to initialize threads before any other line of code was remotely
> reasonable either BTW ;-]
Its really very simple.
Consider that GTK+ is thread aware - that means that the GTK+ code is
littered with calls to g_m
On Mon, Nov 16, 2009 at 2:34 PM, Tristan Van Berkom wrote:
> [...]
>> fact by the threading system ? [ I was never persuaded that glib's
>> demand to initialize threads before any other line of code was remotely
>> reasonable either BTW ;-]
>
Well actually thats
On Tue, Nov 17, 2009 at 1:11 PM, Michael Meeks wrote:
> Hi Tristan,
>
> On Mon, 2009-11-16 at 14:34 -0200, Tristan Van Berkom wrote:
>> > Michael wrote:
>> > fact by the threading system ? [ I was never persuaded that glib's
>> > demand to initialize
On Fri, Nov 20, 2009 at 11:27 AM, Tor Lillqvist wrote:
>> We really need to get our story together here. Either we do our very
>> best to handle late g_thread_init(), or we should fail spectactularly.
>
> Agree 100%.
>
> My own humble opinion is that even GLib (not just GIO) should link to
> -lpth
On Wed, Dec 2, 2009 at 6:52 PM, Shawn Bakhtiar wrote:
[...]
Note that this list is about the development of GTK+ itself, please address
gtk-app-devel-list
or gtk-list in the future for help using the GTK+ apis.
> I'm almost certain, that with glade you would load the xml (containing many
> top l
On Wed, Dec 30, 2009 at 12:48 AM, Paul Davis wrote:
> On Mon, Dec 28, 2009 at 12:02 PM, Holger Berndt wrote:
>> Cross-posting to move the discussion to gtk-devel-list. Anybody interested
>> in the topic, please follow up there.
>>
>> On Do, 24.09.2009 19:23, A. Walton wrote:
>>
>>>It's definitely
On Wed, Dec 30, 2009 at 10:55 PM, Holger Berndt wrote:
> On Mi, 30.12.2009 21:32, Tristan Van Berkom wrote:
>
>>Particularly point 5, nested transactions; I banged my head around that one
>>for a while and finally did not implement this; my interpretation of
>>nested tran
Hey hackers !
This Saturday I wrote a patch[0] that I think can revolutionize
the way we write user interfaces using GTK+, its a short patch for GTK+
but can immensely change how GTK+ can be used; as specially from higher
level bindings.
In a nutshell, GtkComposite is a mechinism that puts Gtk
Hello GTK+ Hackers,
Over the last week I've been working on the extended layout patches[0]
which are sitting in the 'native-layout' branch (the original plan is outlined
in Mathias Hasselmann's blog post[1]).
At this point I'd like to share my findings, plans and uncertainties with the
list s
GtkRequisition*minimum_size,
GtkRequisition*natural_size);
G_END_DECLS
#endif /* __GTK_EXTENDED_LAYOUT_H__ */
/* GTK - The GIMP Toolkit
* Copyright (C) 2010 Openismus GmbH
*
* Author:
* Tristan Van Berkom
*
* This library is free software; you can redistribu
On Fri, Apr 16, 2010 at 5:45 AM, Murray Cumming wrote:
> On Thu, 2010-04-15 at 15:18 -0400, Owen Taylor wrote:
>> I meant that 'height-for-width' is useful, and
>> 'width-for-height' is a bit of gravy on top.
>>
>> That is, "the behavior of text" is useful, the opposite behavior less
>> useful.
>
Good morning,
I've managed to get the base feature set of the native-layout
branch working and in a usable state.
By usable I mean: I've been running Glade on the extended
layout branch for the past week and all of the regressions
I've spotted so far have been fixed, I can also run the
Gimp and
On Fri, Apr 16, 2010 at 3:47 PM, Federico Mena Quintero
wrote:
> Empty containers (well, I just checked GtkBox and GtkTable) will request
> a size of (2 * border_width) if the container is empty.
>
> Shouldn't the requisition be just 0 for such empty containers? Seems
> that this may automaticall
Good morning,
I've managed to get the base feature set of the native-layout
branch working and in a usable state.
By usable I mean: I've been running Glade on the extended
layout branch for the past week and all of the regressions
I've spotted so far have been fixed, I can also run the
Gimp and
On Fri, Apr 23, 2010 at 11:16 PM, Matthias Clasen
wrote:
> On Wed, Apr 21, 2010 at 4:04 AM, Tristan Van Berkom wrote
>
>> I've managed to get the base feature set of the native-layout
>> branch working and in a usable state.
>
> Tristan, thanks so much for getti
On Sun, Apr 25, 2010 at 5:08 PM, Matthias Clasen
wrote:
> On Fri, Apr 23, 2010 at 11:16 PM, Matthias Clasen
> wrote:
>
>> So far, I have found two things that don't seem to work quite right:
>>
>> 1) In testellipsize, when rotating without any ellipsization, the text
>> just 'rotates out' of the
On Sun, Apr 25, 2010 at 9:03 PM, Matthias Clasen
wrote:
> On Sun, Apr 25, 2010 at 5:43 PM, Tristan Van Berkom wrote:
>> On Sun, Apr 25, 2010 at 5:08 PM, Matthias Clasen
>
>>
>> The intention was to ensure the minimum size in the backwards
>> request mode. A horizont
On Mon, Apr 26, 2010 at 6:24 AM, Matthias Clasen
wrote:
> On Sun, Apr 25, 2010 at 10:00 PM, Tristan Van Berkom wrote:
>
>>
>> This will be because GtkFrame still does a classic size request,
>> in this case its getting the minimum height for the minimum width
>> o
On Wed, Jun 16, 2010 at 4:28 PM, Martin Nordholts wrote:
> On 06/16/2010 10:01 PM, Holger Berndt wrote:
>>
>> Some time ago, there was some discussion about a generic undo stack in
>> GTK+ [1]. The talk back then didn't result in more concrete API
>> discussion. As undo/redo is part of the GTK+ Ro
On Mon, Jun 21, 2010 at 7:40 AM, Holger Berndt wrote:
> On Mon, 21 Jun 2010 12:57:44 +0200 ecyrbe wrote:
>
>> Easy Undo/Redo framework are usually based on Inheritance...
>
> I don't have any statistics, but surely, there are many frameworks
> based on inheritance, and many others that aren't. The
On Mon, Jun 21, 2010 at 4:03 PM, Holger Berndt wrote:
[...]
>
> [...]
>
>>You don't want your business logic driven by your onscreen widgets
>>haphazardly this way - you need your undo/redo stack to interface with
>>your internal data model - and you want your views to be synchronized
>>to the mod
Greetings,
Last couple weeks I've been working on the height-for-width
cell renderer api and now I have an intelligible branch for review:
http://git.gnome.org/browse/gtk+/log/?h=native-layout-incubator-2
This branch was created off master and includes a set of
5 or 6 commits (so this branch c
On Fri, Jul 2, 2010 at 12:32 PM, Matthias Clasen
wrote:
> On Wed, Jun 30, 2010 at 12:16 PM, Tristan Van Berkom wrote:
>> Greetings,
>> Last couple weeks I've been working on the height-for-width
>> cell renderer api and now I have an intelligible branch for review:
Greetings,
Last couple weeks I've been working on the height-for-width
cell renderer api and now I have an intelligible branch for review:
http://git.gnome.org/browse/gtk+/log/?h=native-layout-incubator-2
This branch was created off master and includes a set of
5 or 6 commits (so this branch
A nice way to do it would be to subclass your widget and chain up to
the parent expose
method where needed.
if you need to draw generically on widgets, it wont work for all
widgets (some widgets
can have floating subwindows)... but you can be bold and connect to
the "event" signal
and do something
On Wed, 2010-08-25 at 02:42 +0900, Tristan Van Berkom wrote:
[...]
> PS: I've been trying to send this mail all day, at this point from
> several email addresses... I'm dropping the .tgz attachment and will
> follow up with another mail after uploading it somewhere if this emai
On Tue, 2010-08-24 at 20:20 -0400, Matthias Clasen wrote:
> On Tue, Aug 24, 2010 at 1:51 PM, Tristan Van Berkom
> wrote:
> > On Wed, 2010-08-25 at 02:42 +0900, Tristan Van Berkom wrote:
> > [...]
> >> PS: I've been trying to send this mail all day, at this point f
Oops I sent this privately to Hans earlier without CCing the list.
Forwarded Message
From: Tristan Van Berkom
To: Hans Breuer
Subject: Re: Wrapping Box Container
Date: Fri, 27 Aug 2010 11:53:53 +0900
On Tue, 2010-08-24 at 23:09 +0200, Hans Breuer wrote:
> At 24.08.2010 20
On Mon, 2010-08-30 at 22:07 -0400, Havoc Pennington wrote:
> While I'm making trivial comments about wrap box - there's START/END
> in several other enums, rather than BEGIN/END (just look through
> gtkenums.h, wrap box is the only BEGIN)
>
> @GTK_WRAP_BOX_SPREAD_EVEN description says "evenly dist
On Tue, 2010-08-31 at 18:32 -0400, Havoc Pennington wrote:
> Hi,
>
> On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington wrote:
> > With my proposed padding cleanup though that issue goes away:
> >
> > child = g_object_new(TYPE_MYCHILD, "padding", 5, "h-align",
> > GTK_ALIGN_FILL_HORIZONTAL, NULL);
On Wed, 2010-09-01 at 10:51 -0400, Havoc Pennington wrote:
> Hi,
>
> On Wed, Sep 1, 2010 at 6:37 AM, Tristan Van Berkom
> wrote:
> > SPREAD_EVEN is exactly that.. adding extra space between the children as
> > spacing, and there is SPREAD_EXPAND for the other (not s
On Wed, 2010-09-01 at 10:59 -0400, Havoc Pennington wrote:
> Hi,
>
> On Wed, Sep 1, 2010 at 6:41 AM, Tristan Van Berkom
> wrote:
> > I like this idea alot and as its a trivial patch I might write one
> > up tonight or tomorrow ...
>
> well, it's trivial exce
On Sat, 2010-09-04 at 21:37 -0400, Havoc Pennington wrote:
> Hi,
>
> several questions looking at this code,
Sorry it took me a while to answer this mail.
>
> 1. I may be nuts but I really thought set_size_request() could reduce
> a size request below the widget's normal request, back in the da
On Sat, 2010-09-04 at 22:20 -0400, Havoc Pennington wrote:
> 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?
The removed gtk_w
On Tue, 2010-09-07 at 14:44 +0900, Tristan Van Berkom wrote:
> On Sat, 2010-09-04 at 21:37 -0400, Havoc Pennington wrote:
> > Hi,
> >
> > several questions looking at this code,
>
> Sorry it took me a while to answer this mail.
>
> >
> > 1. I may be
Hi,
I've been wanting to write a somewhat trivial patch for
GtkWindow to collapse the GtkOffscreenWindow code completely
as a property of GtkWindow (GtkWindow:offscreen).
The rationale is shamelessly and completely for Glade; here's
our story:
We've been using a hack for the longest time to e
Hi,
With all the GSEAL()ing of the whole GTK+ api we get
to privatize alot of things which leaves us alot more leeway
in how we can change things under the hood in the future.
However, what we have to play with is still a matter of
basic C code implementation details and not much in
the
On Thu, 2010-09-09 at 10:18 -0400, Matthias Clasen wrote:
> On Thu, Sep 9, 2010 at 5:28 AM, Tristan Van Berkom
> wrote:
>
> No comment on your larger refactoring ideas.
>
Right, the point was more about letting us write more
modular code inside of GTK+ without introducing
On Sat, 2010-09-11 at 21:05 -0400, Matthias Clasen wrote:
> On Sat, Sep 11, 2010 at 7:58 PM, Havoc Pennington wrote:
>
> >
> > 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_si
On Sun, 2010-09-12 at 01:01 -0400, Havoc Pennington wrote:
> 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/brows
On Sat, 2010-09-11 at 18:57 +0200, Benjamin Otte wrote:
> On Sat, Sep 11, 2010 at 6:29 PM, Havoc Pennington wrote:
> > - in many languages GtkSizeRequest::get_width() is already just
> > callable as widget.get_width()
> > - plain get_width() more naturally gets request, anyhow
> >
> Ugh, I'd alway
On Sun, 2010-09-12 at 12:53 -0400, Havoc Pennington wrote:
> 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 shoul
On Sun, 2010-09-12 at 01:01 -0400, Havoc Pennington wrote:
> 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/brows
On Sun, 2010-09-12 at 18:50 +0200, Javier Jardón wrote:
> 2010/9/12 Matthias Clasen :
> > We don't have a written-down policy, beyond 'fit in locally'. But I
> > have become increasingly annoyed by trailing whitespace and mixed-in
> > tabs, since they do show up in my editor nowadays. So maybe we s
On Tue, 2010-09-14 at 12:45 -0400, Matthias Clasen wrote:
> This is indeed quite a brain teaser.
>
> I don't think your current approach of incrementally bumping the size
> group requisition does even work correctly. How does the size group
> requisition ever become smaller again ? The pre-hfw siz
On Wed, 2010-09-22 at 15:09 +, Alexander Kuleshov wrote:
> Hello list,
>
> First of all let me introduce myself. My name is Alexander Kuleshov.
> Now I m student, programmer. I have some expirience in C/gtk+
> programming (i took part in Google summer of Code in this year) And I
> want to take
On Thu, 2010-09-23 at 05:05 +, Alexander Kuleshov wrote:
> >You should file bugs in bugzilla and attach patches there
> >for review (or attach patches for existing bugs):
> >https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B
>
> Ok, i understand.
>
> >The current development focus is the
On Tue, 2010-09-14 at 15:00 +0200, Kristian Rietveld wrote:
[...]
> As I also noted in the bug, I would not make GtkTreeViewColumn a stand-alone
> class, rather, I would work on getting the algorithms that do the cell and
> column layouting in separate classes and then have GtkTreeView,
> GtkTre
Please excuse the double-posting here, I neglected to create a new
thread and I really needed this to stand out as a separate subject line.
Sorry.
On Tue, 2010-09-14 at 15:00 +0200, Kristian Rietveld wrote:
[...]
> As I also noted in the bug, I would not make GtkTreeViewColumn a stand-alone
> cl
Guys,
I'm just raising this because it's been the third time now
that I have to fix people's refactor commits locally just to get
through a build.
Today it was:
gdkvisual-x11.c: In function ‘_gdk_visual_init’:
gdkvisual-x11.c:283: error: ‘GdkVisual’ has no member named ‘visual’
gdkvisual-x11.c
Hi all,
With recent developments I've found that GtkWrapBox in the end is
not what was needed to meet the requirements of Glom (hence the writeup
of the different container... coming in another mail).
Furthermore, the gimp's newer versions is now using GtkToolPalette
in place of the older wrap
Hello list again,
Now for the introduction of GtkSpreadTable (still open for
a better name for this widget).
What the spread table container does is takes a linear list
of widgets, which can be of variable size and spread/distribute
the widgets as evenly as possible according to their size
acro
First sorry for the delayed reply... lets just say that
rome was not built in a day ;-)
On Wed, 2010-09-29 at 21:25 +0200, Kristian Rietveld wrote:
> On Sep 23, 2010, at 10:56 AM, Tristan Van Berkom wrote:
> > So to help stay on track without straying too too much, these
> > ar
On Thu, 2010-10-07 at 00:42 -0400, David A Benjamin wrote:
> On Thu, 7 Oct 2010, Tristan Van Berkom wrote:
>
> > Some technical caveats:
> > - When there are over ~12 columns the whole thing slows down
> > significantly.
> >
> > The reason for this
On Thu, 2010-10-07 at 10:03 -0400, Havoc Pennington wrote:
> 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
On Thu, 2010-10-07 at 10:55 -0400, Matthias Clasen wrote:
> 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
> > wit
On Thu, 2010-10-07 at 14:37 -0500, Federico Mena Quintero wrote:
> On Thu, 2010-10-07 at 15:05 -0400, Havoc Pennington wrote:
>
> > 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.
>
> Oh, no, of course not.
On Thu, 2010-10-07 at 14:30 +0900, Tristan Van Berkom wrote:
> On Thu, 2010-10-07 at 00:42 -0400, David A Benjamin wrote:
> > On Thu, 7 Oct 2010, Tristan Van Berkom wrote:
> >
> > > Some technical caveats:
> > > - When there are over ~12 c
On Fri, 2010-10-08 at 14:08 +0200, Murray Cumming wrote:
> On Fri, 2010-10-08 at 20:36 +0900, Tristan Van Berkom wrote:
> > On Fri, 2010-10-08 at 12:13 +0200, Murray Cumming wrote:
> > > On Thu, 2010-10-07 at 12:37 +0900, Tristan Van Berkom wrote:
> > > > Hello list
On Fri, 2010-10-08 at 12:13 +0200, Murray Cumming wrote:
> On Thu, 2010-10-07 at 12:37 +0900, Tristan Van Berkom wrote:
> > Hello list again,
> >Now for the introduction of GtkSpreadTable (still open for
> > a better name for this widget).
> >
> > What the spr
On Fri, 2010-10-08 at 16:51 +0900, Tristan Van Berkom wrote:
> On Thu, 2010-10-07 at 14:30 +0900, Tristan Van Berkom wrote:
> > On Thu, 2010-10-07 at 00:42 -0400, David A Benjamin wrote:
> > > On Thu, 7 Oct 2010, Tristan Van Berkom wrote:
> > >
> > > > S
On Fri, 2010-10-08 at 15:38 +0200, Murray Cumming wrote:
> On Fri, 2010-10-08 at 21:23 +0900, Tristan Van Berkom wrote:
> > On Fri, 2010-10-08 at 14:08 +0200, Murray Cumming wrote:
> > > On Fri, 2010-10-08 at 20:36 +0900, Tristan Van Berkom wrote:
> > > > On Fri, 201
On Fri, 2010-10-08 at 20:56 +0900, Tristan Van Berkom wrote:
> On Fri, 2010-10-08 at 16:51 +0900, Tristan Van Berkom wrote:
> > On Thu, 2010-10-07 at 14:30 +0900, Tristan Van Berkom wrote:
> > > On Thu, 2010-10-07 at 00:42 -0400, David A Benjamin wrote:
> > > > O
Hi all,
So I'm spending some time trying to get Glade to at least build
on 3.0...
First thing, what is the recommended way of doing
gdk_window_set_back_pixmap (from xpm data...) ?
Sure... I'm seeing gdk_window_set_background_pattern()..
but no way to create the pattern from a pixbuf or su
On Sat, 2010-10-09 at 13:18 -0400, Matthias Clasen wrote:
> On Sat, Oct 9, 2010 at 2:56 AM, Tristan Van Berkom
[...]
> > And... please, please... if removing the expose completely
> > is acceptable... can we then go ahead and remove ->size_request()
> > as well ?
>
>
On Sun, 2010-10-10 at 02:14 -0400, Matthias Clasen wrote:
> On Thu, Oct 7, 2010 at 11:30 AM, Tristan Van Berkom
> wrote:
> > On Thu, 2010-10-07 at 10:55 -0400, Matthias Clasen wrote:
> >> On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom
> >> wrote:
>
On Sun, 2010-10-10 at 17:23 +0900, Tristan Van Berkom wrote:
> On Sun, 2010-10-10 at 02:14 -0400, Matthias Clasen wrote:
> > On Thu, Oct 7, 2010 at 11:30 AM, Tristan Van Berkom
> > wrote:
> > > On Thu, 2010-10-07 at 10:55 -0400, Matthias Clasen wrote:
> > >
On Sun, 2010-10-10 at 10:10 -0400, Havoc Pennington wrote:
> 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 pa
On Sun, 2010-10-10 at 12:34 -0400, Havoc Pennington wrote:
> 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 poin
On Mon, 2010-10-11 at 11:04 +0200, Murray Cumming wrote:
> On Fri, 2010-10-08 at 23:31 +0900, Tristan Van Berkom wrote:
> > For what its worth I finally applied this algorithm
> > to the 'spread-table' branch.
> >
> > In the case that the trailing columns get
On Mon, 2010-10-11 at 11:06 +0200, Murray Cumming wrote:
> On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote:
> > Furthermore, the gimp's newer versions is now using GtkToolPalette
> > in place of the older wrap-box (the gimp had been using a similar
> > wra
On Mon, 2010-10-11 at 13:04 +0200, Murray Cumming wrote:
> On Mon, 2010-10-11 at 19:54 +0900, Tristan Van Berkom wrote:
> > On Mon, 2010-10-11 at 11:06 +0200, Murray Cumming wrote:
> > > On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote:
> > > > Furthermore
On Mon, 2010-10-11 at 13:01 +0200, Murray Cumming wrote:
> On Mon, 2010-10-11 at 19:48 +0900, Tristan Van Berkom wrote:
> > On Mon, 2010-10-11 at 11:04 +0200, Murray Cumming wrote:
> > > On Fri, 2010-10-08 at 23:31 +0900, Tristan Van Berkom wrote:
> > > > For what it
Sigh, alright can of worms open.
Not sure exactly where to start here but lets keep in mind that
of course, any window must fit all of its screen content at all
times, that's not to say that it requires the
minimum-height-for-minimum-width at all times, but only when it's
allocated it's minimum w
On Tue, 2010-10-12 at 09:45 -0400, Havoc Pennington wrote:
> 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:
> >> &g
On Tue, 2010-10-12 at 10:21 -0400, Havoc Pennington wrote:
> 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
On Tue, 2010-10-12 at 12:09 -0400, Owen Taylor wrote:
> On Tue, 2010-10-12 at 15:44 +0900, Tristan Van Berkom wrote:
>
> [...]
>
> > Also... lets try to break this down into two separate issues at hand.
> >
> > First issue being that the window requires enough
On Tue, 2010-10-12 at 13:27 -0400, Havoc Pennington wrote:
> 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 GT
On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote:
> Hi all,
> With recent developments I've found that GtkWrapBox in the end is
> not what was needed to meet the requirements of Glom (hence the writeup
> of the different container... coming in another mail).
FW
On Sun, 2010-10-10 at 03:01 +0900, Tristan Van Berkom wrote:
> On Sat, 2010-10-09 at 13:18 -0400, Matthias Clasen wrote:
> > On Sat, Oct 9, 2010 at 2:56 AM, Tristan Van Berkom
> [...]
> > > And... please, please... if removing the expose completely
> > > is acceptab
On Wed, 2010-10-13 at 02:50 +0900, Tristan Van Berkom wrote:
> On Tue, 2010-10-12 at 13:27 -0400, Havoc Pennington wrote:
> > Hi,
> >
> > On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington wrote:
> > > d) max size widget can do something useful with
> > > e
On Thu, 2010-10-14 at 10:45 -0400, Havoc Pennington wrote:
> 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
On Fri, 2010-10-15 at 09:55 -0400, Havoc Pennington wrote:
> 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 ->adjus
On Fri, 2010-10-15 at 11:32 -0400, Havoc Pennington wrote:
> 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_widt
ver 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-
On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
> 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
> > c
On Thu, 2010-10-21 at 13:57 +0900, Tristan Van Berkom wrote:
> On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
> > Hi,
> >
> > On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
> > wrote:
> > >
> > > What happens when another subclas
On Thu, 2010-10-21 at 14:10 +0900, Tristan Van Berkom wrote:
> On Thu, 2010-10-21 at 13:57 +0900, Tristan Van Berkom wrote:
> > On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
> > > Hi,
> > >
> > > On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berko
On Thu, 2010-10-21 at 14:51 +0900, Tristan Van Berkom wrote:
> On Thu, 2010-10-21 at 14:10 +0900, Tristan Van Berkom wrote:
> > On Thu, 2010-10-21 at 13:57 +0900, Tristan Van Berkom wrote:
> > > On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
> > > > Hi,
&
On Thu, 2010-10-21 at 17:33 +0100, Richard Hughes wrote:
> How about, if you plan to break API, it's mandatory to write entries
> in the migration guide. Heck, even a quick email to the mailing list
> explaining how to convert code might be nice.
>
> I'm getting really tired from people changing b
On Thu, 2010-10-21 at 17:52 +0100, Bastien Nocera wrote:
> On Fri, 2010-10-22 at 01:48 +0900, Tristan Van Berkom wrote:
> > On Thu, 2010-10-21 at 17:33 +0100, Richard Hughes wrote:
> > > How about, if you plan to break API, it's mandatory to write entries
> > > in t
On Tue, 2010-10-12 at 14:51 +0200, Kristian Rietveld wrote:
> On Thu, Oct 7, 2010 at 6:41 AM, Tristan Van Berkom
> wrote:
> > I was thinking that a GtkCellArea would only render a single row
> > (actually, a row in a treeview can be composed of several GtkCellAreas,
> > ea
On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
> On Sat, Oct 23, 2010 at 9:44 AM, Tristan Van Berkom
> wrote:
> > I'm a few days into this and I've written up a GtkCellAreaClass and
> > started out implementing an orientable GtkCellAreaBoxClass.
> >
On Tue, 2010-10-26 at 09:23 +0200, Kristian Rietveld wrote:
> On Tue, Oct 26, 2010 at 3:28 AM, Tristan Van Berkom
> wrote:
> > On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
> > Hmm seems I didn't communicate this clearly enough, GtkCellArea
> >
On Tue, 2010-10-26 at 16:54 +0900, Tristan Van Berkom wrote:
> On Tue, 2010-10-26 at 09:23 +0200, Kristian Rietveld wrote:
> > On Tue, Oct 26, 2010 at 3:28 AM, Tristan Van Berkom
> > wrote:
> > > On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
> > > Hm
On Tue, 2010-10-26 at 18:32 +0900, Tristan Van Berkom wrote:
> On Tue, 2010-10-26 at 16:54 +0900, Tristan Van Berkom wrote:
> > On Tue, 2010-10-26 at 09:23 +0200, Kristian Rietveld wrote:
> > > On Tue, Oct 26, 2010 at 3:28 AM, Tristan Van Berkom
> > > wrote:
> >
On Tue, 2010-10-26 at 21:43 -0400, Matthias Clasen wrote:
> On Tue, Oct 26, 2010 at 8:26 PM, Matthias Clasen
> wrote:
>
> > Proposed plan:
> >
> > 1. nuke size-request in GTK+
> > 2. deprecate size-request in 2.91.3 (we can't use #ifdef deprecation
> > for vfuncs, but maybe we can arrange things
On Wed, 2010-10-27 at 13:24 +0900, Tristan Van Berkom wrote:
> On Tue, 2010-10-26 at 21:43 -0400, Matthias Clasen wrote:
> > On Tue, Oct 26, 2010 at 8:26 PM, Matthias Clasen
> > wrote:
> >
> > > Proposed plan:
> > >
> > > 1. nuke size-request in GT
On Thu, 2010-10-28 at 15:47 +0900, Tristan Van Berkom wrote:
> On Wed, 2010-10-27 at 13:24 +0900, Tristan Van Berkom wrote:
> > On Tue, 2010-10-26 at 21:43 -0400, Matthias Clasen wrote:
> > > On Tue, Oct 26, 2010 at 8:26 PM, Matthias Clasen
> > > wrote:
&
On Thu, 2010-10-28 at 22:38 +0200, Alexander Larsson wrote:
> One thing I remember being really confused about when learning gtk+ is
> the GSList * usage for the group in GtkRadioButton. We have added some
> scaffolding now that makes this somewhat better, but whats the chance of
> actually fixing
1 - 100 of 370 matches
Mail list logo
