On Mon, 2010-11-01 at 17:37 +0900, Tristan Van Berkom wrote:
On Mon, 2010-11-01 at 15:15 +0900, Tristan Van Berkom wrote:
On Mon, 2010-11-01 at 12:15 +0900, Tristan Van Berkom wrote:
On Sun, 2010-10-31 at 17:45 +0100, Kristian Rietveld wrote:
On Sun, Oct 31, 2010 at 3:17 PM, Tristan Van
On Mon, 2010-11-01 at 12:15 +0900, Tristan Van Berkom wrote:
On Sun, 2010-10-31 at 17:45 +0100, Kristian Rietveld wrote:
On Sun, Oct 31, 2010 at 3:17 PM, Tristan Van Berkom
trista...@openismus.com wrote:
Whew, ok I implemented GtkCellArea-render for GtkCellAreaBox for the
most part,
On Mon, 2010-11-01 at 15:15 +0900, Tristan Van Berkom wrote:
On Mon, 2010-11-01 at 12:15 +0900, Tristan Van Berkom wrote:
On Sun, 2010-10-31 at 17:45 +0100, Kristian Rietveld wrote:
On Sun, Oct 31, 2010 at 3:17 PM, Tristan Van Berkom
trista...@openismus.com wrote:
Whew, ok I
On Mon, Nov 1, 2010 at 2:15 AM, Tristan Van Berkom
trista...@openismus.com wrote:
Well... as I've already said I havent figured out a
solution for this... I'm all ears.
Look at gtk_container_focus_sort for how we deal with directional
navigation in widgets. It notably doesn't handle
On Wed, 2010-10-27 at 08:59 +0200, Kristian Rietveld wrote:
On Tue, Oct 26, 2010 at 6:34 PM, Tristan Van Berkom
trista...@openismus.com wrote:
Depending on the GtkSizeRequestMode in use by the parenting
layout widget (hfw of wfh), generally only allocate_width()
or allocate_height() will
On Sun, 2010-10-31 at 15:21 +0900, Tristan Van Berkom wrote:
On Wed, 2010-10-27 at 08:59 +0200, Kristian Rietveld wrote:
On Tue, Oct 26, 2010 at 6:34 PM, Tristan Van Berkom
trista...@openismus.com wrote:
Depending on the GtkSizeRequestMode in use by the parenting
layout widget (hfw of
On Sun, Oct 31, 2010 at 7:21 AM, Tristan Van Berkom
trista...@openismus.com wrote:
Ok so I'm pretty much finished the request/allocation code... I've got
as far as having a list of renderers with allocated positions and sizes
come time for -render()/-event() etc.
If I understand correctly
On Sun, Oct 31, 2010 at 3:17 PM, Tristan Van Berkom
trista...@openismus.com wrote:
Whew, ok I implemented GtkCellArea-render for GtkCellAreaBox for the
most part, however I'm still missing the GtkCellRendererState flags ;-)
So for this part I was thinking it might make more sense to create
a
On Sun, 2010-10-31 at 17:30 +0100, Kristian Rietveld wrote:
On Sun, Oct 31, 2010 at 7:21 AM, Tristan Van Berkom
trista...@openismus.com wrote:
Ok so I'm pretty much finished the request/allocation code... I've got
as far as having a list of renderers with allocated positions and sizes
come
On Sun, 2010-10-31 at 17:45 +0100, Kristian Rietveld wrote:
On Sun, Oct 31, 2010 at 3:17 PM, Tristan Van Berkom
trista...@openismus.com wrote:
Whew, ok I implemented GtkCellArea-render for GtkCellAreaBox for the
most part, however I'm still missing the GtkCellRendererState flags ;-)
So
On Tue, Oct 26, 2010 at 6:34 PM, Tristan Van Berkom
trista...@openismus.com wrote:
Depending on the GtkSizeRequestMode in use by the parenting
layout widget (hfw of wfh), generally only allocate_width()
or allocate_height() will be called. However there will be
cases where we get to further
On Tue, Oct 26, 2010 at 3:28 AM, Tristan Van Berkom
trista...@openismus.com wrote:
On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
Hmm seems I didn't communicate this clearly enough, GtkCellArea
is a base abstract class, and GtkCellAreaBox is the first concrete
subclass of
On Tue, 2010-10-26 at 09:23 +0200, Kristian Rietveld wrote:
On Tue, Oct 26, 2010 at 3:28 AM, Tristan Van Berkom
trista...@openismus.com wrote:
On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
Hmm seems I didn't communicate this clearly enough, GtkCellArea
is a base abstract
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
trista...@openismus.com wrote:
On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
Hmm seems I didn't
On Sat, Oct 23, 2010 at 9:44 AM, Tristan Van Berkom
trista...@openismus.com wrote:
I'm a few days into this and I've written up a GtkCellAreaClass and
started out implementing an orientable GtkCellAreaBoxClass.
An initial problem here has to do with pushing data to the GtkCellArea
instead of
On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
On Sat, Oct 23, 2010 at 9:44 AM, Tristan Van Berkom
trista...@openismus.com wrote:
I'm a few days into this and I've written up a GtkCellAreaClass and
started out implementing an orientable GtkCellAreaBoxClass.
An initial
On Tue, 2010-10-12 at 14:51 +0200, Kristian Rietveld wrote:
On Thu, Oct 7, 2010 at 6:41 AM, Tristan Van Berkom
trista...@openismus.com 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,
each
On Thu, Oct 7, 2010 at 6:41 AM, Tristan Van Berkom
trista...@openismus.com 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,
each treeview column would use exactly one cell area to abstract a lot
of
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
are (my perceived) reasons
On Sep 23, 2010, at 10:56 AM, Tristan Van Berkom wrote:
So to help stay on track without straying too too much, these
are (my perceived) reasons for the said refactoring work:
- Code sharing: A good refactoring of cell layouting logic
into some classes that can be (more) easily reused
(Tristan, I will be replying to your main e-mail as soon as possible. As you
might understand I need some more time for that :)).
On Sep 23, 2010, at 4:22 PM, Enrico Weigelt wrote:
* Tristan Van Berkom trista...@openismus.com schrieb:
Hi,
big_snip /
Just an naive half-OT question in
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,
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
Hi,
On Sep 9, 2010, at 11:28 AM, Tristan Van Berkom wrote:
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
On Thu, Sep 9, 2010 at 5:28 AM, Tristan Van Berkom
trista...@openismus.com wrote:
No comment on your larger refactoring ideas.
Are there any technical limitations that dont allow us to create
widget/object types that are completely internal to GTK+ ?
GObject has no notion of private types.
On Thu, 2010-09-09 at 10:18 -0400, Matthias Clasen wrote:
On Thu, Sep 9, 2010 at 5:28 AM, Tristan Van Berkom
trista...@openismus.com 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 Thu, Sep 9, 2010 at 12:42 PM, Tristan Van Berkom
trista...@openismus.com wrote:
Well, are we comfortable writing code in this way and telling
people that if it's not in the headers and not in the docs,
it's not a backwards/forwards compatible type and people are
simply not supposed to
On Thu, Sep 9, 2010 at 1:19 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
I don't think it is worth it. We already have some de-facto private
types along the lines outlined above: GtkFileSystem, GtkFolder,
GtkFileSystemModel, GtkPrintBackend...
I think it is generally ok to do this as
28 matches
Mail list logo
