Hi!
It will probably work if you make the cells editable (
https://developer.gnome.org/gtk3/stable/GtkCellRendererText.html#GtkCellRendererText--editable
).
Alternatively, you could write your own cell renderer (maybe inheriting
GtkCellRendererText) to handle the selection yourself.
Regards,
Vi
On 23 Sep 2011, at 10:55, Dieter Verfaillie wrote:
> Hi John,
>
> Thanks for having another look at this!
>
> [...]
>
> I'll have to point out that the current proposed patch on bug #616544 [1]
> is more subtle than you think in that it is not a plain revert. It already
> does the right thing f
Hi John,
Thanks for having another look at this!
On Fri, 23 Sep 2011 10:20:37 +0100, John Emmas wrote:
Just a final footnote to this issue (hopefully):-
I noticed pbor's comment in bugzilla about the inelegant use of
'dest_window' so I checked our mods and realised that we'd probably
reverted
Just a final footnote to this issue (hopefully):-
I noticed pbor's comment in bugzilla about the inelegant use of 'dest_window'
so I checked our mods and realised that we'd probably reverted too much of the
function. In fact, only the first 10 lines or so need to be reverted. The
remainder ca
On Mon, Sep 19, 2011 at 6:09 PM, Doug Blank wrote:
> On Mon, Sep 19, 2011 at 5:56 PM, Paul Davis
> wrote:
>> On Mon, Sep 19, 2011 at 4:42 PM, Doug Blank wrote:
>>> On Mon, Sep 19, 2011 at 4:10 PM, Paul Davis
>>> wrote:
On Mon, Sep 19, 2011 at 4:05 PM, Doug Blank wrote:
> BTW, d
On Mon, Sep 19, 2011 at 5:56 PM, Paul Davis wrote:
> On Mon, Sep 19, 2011 at 4:42 PM, Doug Blank wrote:
>> On Mon, Sep 19, 2011 at 4:10 PM, Paul Davis
>> wrote:
>>> On Mon, Sep 19, 2011 at 4:05 PM, Doug Blank wrote:
>>>
BTW, do you think that these fixes will have any effect on Mac OSX? I
On Mon, Sep 19, 2011 at 5:58 PM, Paul Davis wrote:
> On Mon, Sep 19, 2011 at 4:42 PM, Doug Blank wrote:
>> On Mon, Sep 19, 2011 at 4:10 PM, Paul Davis
>> wrote:
>>> On Mon, Sep 19, 2011 at 4:05 PM, Doug Blank wrote:
>>>
BTW, do you think that these fixes will have any effect on Mac OSX? I
On Mon, Sep 19, 2011 at 4:42 PM, Doug Blank wrote:
> On Mon, Sep 19, 2011 at 4:10 PM, Paul Davis
> wrote:
>> On Mon, Sep 19, 2011 at 4:05 PM, Doug Blank wrote:
>>
>>> BTW, do you think that these fixes will have any effect on Mac OSX? I
>>> am getting the same behavior there, and am hopeful tha
On Mon, Sep 19, 2011 at 4:42 PM, Doug Blank wrote:
> On Mon, Sep 19, 2011 at 4:10 PM, Paul Davis
> wrote:
>> On Mon, Sep 19, 2011 at 4:05 PM, Doug Blank wrote:
>>
>>> BTW, do you think that these fixes will have any effect on Mac OSX? I
>>> am getting the same behavior there, and am hopeful tha
On 19/09/2011 22:05, Doug Blank wrote:
> BTW, do you think that these fixes will have any effect on Mac OSX? I
> am getting the same behavior there, and am hopeful that we can restore
> functionality there too.
No, these are specific to the win32 GDK backend. Sorry.
mvg,
Dieter
On Mon, Sep 19, 2011 at 4:10 PM, Paul Davis wrote:
> On Mon, Sep 19, 2011 at 4:05 PM, Doug Blank wrote:
>
>> BTW, do you think that these fixes will have any effect on Mac OSX? I
>> am getting the same behavior there, and am hopeful that we can restore
>> functionality there too.
>
> which behavi
On Mon, Sep 19, 2011 at 4:05 PM, Doug Blank wrote:
> BTW, do you think that these fixes will have any effect on Mac OSX? I
> am getting the same behavior there, and am hopeful that we can restore
> functionality there too.
which behaviour? DnD on OS X with 2.24 built with the gtk-osx
moduleset w
On Mon, Sep 19, 2011 at 2:55 PM, Dieter Verfaillie
wrote:
> On 18/09/2011 13:10, John Emmas wrote:
>> On 18 Sep 2011, at 11:54, Dieter Verfaillie wrote:
>>
>>>
>>> Probably best to attach this to some bug report and start marking
>>> the other TreeView DnD related reports as duplicates. Then we ha
On 18/09/2011 13:10, John Emmas wrote:
> On 18 Sep 2011, at 11:54, Dieter Verfaillie wrote:
>
>>
>> Probably best to attach this to some bug report and start marking
>> the other TreeView DnD related reports as duplicates. Then we have
>> a bug report to show the maintainers (I think that's the pr
On 18/09/2011 13:39, Dieter Verfaillie wrote:
> On 18/09/2011 13:10, John Emmas wrote:
>> Can I leave that to you then, Dieter? It sounds like you're a
>> bit more experienced in that area than I am.
>
> Sure. I'll start looking into it this afternoon/evening.
Well, things never seem to go the w
On 18 Sep 2011, at 00:03, Dieter Verfaillie wrote:
>
> ps For future reference: GTK+ development related discussions
> are better done one gtk-devel-list. You'll probably attract
> more GTK+ developers/maintainers over there. There's also
> a #win32 channel on irc.gnome.org in need of being repop
On 18/09/2011 13:10, John Emmas wrote:
> Can I leave that to you then, Dieter? It sounds like you're a
> bit more experienced in that area than I am.
Sure. I'll start looking into it this afternoon/evening. Feel free
to still drop by on irc.gnome.org though (#win32 should serve us
well to prepare
On Sun, 2011-09-18 at 12:04 +0200, Dieter Verfaillie wrote:
> On 18/09/2011 11:00, Dieter Verfaillie wrote:
> > This does most likely does break the wip generic OLE DnD method
> > though, but I'm not sure if we should care much about that in
> > the 2.24 branch?
>
> Cleaned up patch fixing the abo
On Sun, 2011-09-18 at 01:03 +0200, Dieter Verfaillie wrote:
> To clarify, I've ran "GDK_DEBUG=dnd testtreeview.exe" for
> both GTK+ versions.
>
> Looking at the output (the gdk_drag_find_window lines are
> the interesting bits), it seems dest_window is not yet
> correctly determined in 2.24. With
On 18 Sep 2011, at 11:54, Dieter Verfaillie wrote:
>
> Probably best to attach this to some bug report and start marking
> the other TreeView DnD related reports as duplicates. Then we have
> a bug report to show the maintainers (I think that's the preferred
> way of working) and it's shows me me
On 18/09/2011 12:18, John Emmas wrote:
> On 18 Sep 2011, at 10:00, Dieter Verfaillie wrote:
>> Reverting gdk_drag_find_window_for_screen to the 2.16 era logic
>> effectively fixes treeview dnd (see attached patch). Have not yet
>> tested if this breaks other things so this patch needs more work.
>
On 18 Sep 2011, at 10:00, Dieter Verfaillie wrote:
>
> Reverting gdk_drag_find_window_for_screen to the 2.16 era logic
> effectively fixes treeview dnd (see attached patch). Have not yet
> tested if this breaks other things so this patch needs more work.
>
Great news! The patch is quite strai
On 18/09/2011 11:00, Dieter Verfaillie wrote:
> This does most likely does break the wip generic OLE DnD method
> though, but I'm not sure if we should care much about that in
> the 2.24 branch?
Cleaned up patch fixing the above. Tested various DnD
operations with testtreeview and gtk-demo. Togeth
On 18/09/2011 01:03, Dieter Verfaillie wrote:
> Currently, my best guess is that the WindowFromPoint() call
> doesn't give us the hwnd we're supposed to get in this case
> (in gdkdnd-win32.c::gdk_drag_find_window_for_screen(), around
> line 1988 with Peter's patches applied).
Digging deeper, it is
On Sat, Sep 17, 2011 at 10:25:58AM +0100, John Emmas wrote:
> >
> FWIW I just tried a quick test but the address being printed doesn't
> seem to be the main window's address. At the moment, I'm a bit
> puzzled about what it might be
It might be the DnD icon (or whatever) window. You can add
On 17 Sep 2011, at 23:21, Peter Clifton wrote:
>
> Have you tried the GTK patches I pointed you at here?
>
> www.clifton-electronics.com/tmp/gtk_win32_patches.tar.gz
>
Sorry Peter. Your patches are on my TODO list but I haven't had time to look
at them yet. My gut feeling (though I'd love t
On 18/09/2011 00:21, Peter Clifton wrote:
> On Sat, 2011-09-17 at 18:49 +0100, John Emmas wrote:
>
> Have you tried the GTK patches I pointed you at here?
>
> www.clifton-electronics.com/tmp/gtk_win32_patches.tar.gz
I've just completed testing 2.24 with your patches (good
stuff, thanks!) and com
On Sat, 2011-09-17 at 18:49 +0100, John Emmas wrote:
Have you tried the GTK patches I pointed you at here?
www.clifton-electronics.com/tmp/gtk_win32_patches.tar.gz
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridg
On 17 Sep 2011, at 10:25, John Emmas wrote:
>
> FWIW I just tried a quick test but the address being printed doesn't seem to
> be the main window's address. At the moment, I'm a bit puzzled about what it
> might be
>
I'm no closer to knowing which widget address is getting sent but I th
On 17 Sep 2011, at 09:14, John Emmas wrote:
>
> So I think this confirms that in gtk-win32, the wrong window is getting
> tested for a TreeView control. I suppose the quest now must be to find out
> which window and why. I'm guessing that in my case it might be the app's
> main window but I
Hi David, here's what I got when I added your function calls this morning.
Firstly, a non-treeview test example. This example has a main window (a
dialog) with two labels, one of which is the drop target. The dialog also
launches a child dialog. Here's what I see when I drag one label onto th
On Tue, 2011-09-13 at 09:14 +0100, John Emmas wrote:
> I was thinking of setting aside some time to investigate this but then
> I noticed that gtk is now up to version 2.24. I just wondered if the
> problem is fixed in 2.24 - or if anyone else knows about this problem
> or is already working on i
Thanks for that, Yeti. That output is very much like the output I see on
Windows when using non-treeview DnD sources.
Unfortunately I've got an early start at work tomorrow so it probably won't be
until Saturday when I get a chance to try that in my Windows build. I'll let
you know what I fin
On Thu, Sep 15, 2011 at 08:16:50PM +0100, John Emmas wrote:
> Okay - not sure how far you'll be able to get with only pre-built Wine
> binaries. I suppose you could at least let us know whether the
> pointer addresses on Linux look sensible though (the first printout to
> appear should be the corr
On 15 Sep 2011, at 20:04, David Nečas wrote:
>
> I can do this as I am in the opposite situation (having Gtk+ built from
> source on Linux but only pre-built Win32 binaries – and also no real MS
> Windows, just Wine). Do you want me to use a specific Gtk+ version?
>
Okay - not sure how far you
On Thu, Sep 15, 2011 at 07:51:47PM +0100, John Emmas wrote:
> P.S. - what'd be really interesting would be to see what gets printed on
> Linux. Unfortunately, I can't do this locally because on Linux, I'm using
> pre-built binaries. However, someone else might be able to look at that.
I can do
P.S. - what'd be really interesting would be to see what gets printed on Linux.
Unfortunately, I can't do this locally because on Linux, I'm using pre-built
binaries. However, someone else might be able to look at that.
John
___
gtk-list mailing list
On 15 Sep 2011, at 18:35, David Nečas wrote:
>
> Could you please post the debugging code in the form of a patch so that
> others can easily and precisely reproduce it?
>
That's not quite as simple as I'd hope because I'm not using a version control
system (at the moment). However, the 2 func
On Thu, Sep 15, 2011 at 06:15:30PM +0100, John Emmas wrote:
>
> What I found was that the "gtk-drag-dest" data was being correctly set for
> the drop target. You can check this by doing the following:-
> ...
Could you please post the debugging code in the form of a patch so that
others can easi
Thanks for the prompt help with this, guys. I took a look at David's
suggestion
On 15 Sep 2011, at 14:32, David Nečas wrote:
>
> So IMO you need to go one level up and look at what ‘widget’ is and why
> it does not have any "gtk-drag-dest" data. AFAIK the data can be
> attached by gtk_dra
On Thu, Sep 15, 2011 at 01:56:05PM +0100, John Emmas wrote:
> ...
> gtk_drag_find_widget (toplevel, &data);
>
> and it's that function which invokes the callback. Inside that function, the
> relevant code looks like this:-
>
> if (!data->found && g_object_get_data (G_OBJECT (widget), "gtk-drag-
On Thursday, September 15, 2011 1:56 PM, "John Emmas"
wrote:
> In gtk-win32, when 'key' == "gtk-drag-dest" (and the drag destination is
> a TreeView) 'g_datalist_id_get_data()' returns NULL. This is where my
> understanding of GTK comes to a halt. Obviously there's some kind of
> data list which
On Thu, Sep 15, 2011 at 8:56 AM, John Emmas wrote:
> I found out what's going wrong here. I don't quite understand why it's going
> wrong but i do know where it's going wrong. Do any GTK+ devs come onto this
> forum? If so, they might be able to chip in with some information that will
> help
I found out what's going wrong here. I don't quite understand why it's going
wrong but i do know where it's going wrong. Do any GTK+ devs come onto this
forum? If so, they might be able to chip in with some information that will
help to get this fixed. Although I'm a competent programmer I'm
On 13 Sep 2011, at 15:47, John Emmas wrote:
>
> zero equates to GDK_ACTION_DEFAULT which is a valid setting AFAICT.
>
Oops, wait a minute I was reading it wrong. GDK_ACTION_DEFAULT is in fact
1, not zero. So we're back to finding out why and where it's getting set to
zero. At least we
On 13 Sep 2011, at 11:59, dieterv wrote:
> On Tue, 13 Sep 2011 11:18:50 +0100, John Emmas wrote:
>>
>> Normally, 'info->context->action' would be whatever action you'd set
>> it to (GDK_ACTION_MOVE / GDK_ACTION_COPY / GDK_ACTION_ASK etc). But
>> by the time the code reaches that point the actio
On Tue, 13 Sep 2011 11:18:50 +0100, John Emmas wrote:
Thanks Dieter. I was particularly interested to read that apparently
this did once work. Also, the fact that it can be made to work after
a fashion by using 'gtk_drag_source_set() / dest_set()' instead of
the
official 'gtk_tree_view_enable
On Tue, Sep 13, 2011 at 4:46 AM, dieterv wrote:
> On Tue, 13 Sep 2011 09:14:13 +0100, John Emmas wrote:
>>
>> I was thinking of setting aside some time to investigate this but
>
> A lot of people will thank you if you do :)
More people than you could imagine.
>> then I noticed that gtk is now up
On 13 Sep 2011, at 09:46, dieterv wrote:
>
> I'm still seeing it on 2.24 and think these bug reports
> are related:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=641924
> https://bugzilla.gnome.org/show_bug.cgi?id=652235
>
Thanks Dieter. I was particularly interested to read that apparentl
On Tue, 13 Sep 2011 09:14:13 +0100, John Emmas wrote:
I was thinking of setting aside some time to investigate this but
A lot of people will thank you if you do :)
then I noticed that gtk is now up to version 2.24. I just wondered
if
the problem is fixed in 2.24 - or if anyone else knows ab
weo wu wrote:
HI guys:
I'm a newbie in gtk+ , I have many questions about
the GtkTreeView .Somebody ever told me that the Gtk+
2.0 Tree View tutorial is usefull,but I could not
visit the websit
scentric.net/tutorial/treeview-tutorial. pdf
which contains the tutorial (is this url is invalid?).
I e
A really good way to learn gtk is to work with the
python bindings, pygtk.
There is a good pygtk tutorial for the treeview here:
http://liw.iki.fi/liw/texts/gtktreeview-tutorial.html
There are also a whole section on the treeview in the pygtk faq:
http://www.async.com.br/faq/pygtk/index.py?
Thanks very much indeed for this pointer, armed with
this info I've speeded up the loading of my grids by a factor of 5.
I had been trying:
TreeViewColumn::set_fixed_width()
and
TreeViewColumn::set_sizing(TREE_VIEW_COLUMN_FIXED)
but hadn't noticed CellRenderer::set_fixed_size(width,
he
Igor Gorbounov wrote:
Hi, All!
My application uses a TreeView (using ListStore model) table to present
measured data
once per second. This table has about 20 rows and about 40 columns.
The problem is in consuming too much CPU resources (about 14% when the
table is
switched on, and near 3% when it
Igor Gorbounov wrote:
John Gill wrote:
[]
My suspicion is that the treeview is calculating the layout of the
renderers within the the fixed width of each column. I'm guessing
if there was an option to stop it doing this (since its initial
layout is more than good enough for me) that we wou
John Gill wrote:
[]
My suspicion is that the treeview is calculating the layout of the
renderers within the the fixed width of each column. I'm guessing if
there was an option to stop it doing this (since its initial layout is
more than good enough for me) that we would see a dramatic spee
I've been running into similar performance issues with
the TreeView, using a liststore containing thousands of rows.
For example, with about 40K rows with 10 columns the data loads into
the store quickly and then the cpu races for around 30-40 seconds. I
think what is going on is the treevi
On Fri, 2004-01-16 at 18:33, Chris De Maeyer wrote:
> On Fri, 2004-01-16 at 13:50, Brice LEROY wrote:
> > Hello,
> > I looking for a solution to deallocate a liststore loaded in a
> > treeview. If you know a function to get the pointer to the
> > gtk_list_store loaded in a treeview to dele
g_object_unref (G_OBJECT (store));
On Fri, 2004-01-16 at 13:50, Brice LEROY wrote:
> Hello,
> I looking for a solution to deallocate a liststore loaded in a
> treeview. If you know a function to get the pointer to the
> gtk_list_store loaded in a treeview to delete with g_free() this
> var
* Tim Evans ([EMAIL PROTECTED]) wrote:
> It is possible, just not particularly obvious. What you need to do is
> call gtk_tree_view_column_set_widget, passing in your own label that is
> set to display the column title. Once the label is shown and realized,
> call gtk_widget_get_parent three t
Tim Evans wrote:
>It is possible, just not particularly obvious. What you need to do is
>call gtk_tree_view_column_set_widget, passing in your own label that is
>set to display the column title. Once the label is shown and realized,
>call gtk_widget_get_parent three times, which should move up t
Carl B. Constantine wrote:
* Mike Dailey ([EMAIL PROTECTED]) wrote:
Is it possible to change the foreground and background
color of the column header in a GTK TreeView, using a
ListStore as the model?
Nope, I tried and tried. the Header lables, AFAICT, cannot be changed
from the standard colors
* Mike Dailey ([EMAIL PROTECTED]) wrote:
> Is it possible to change the foreground and background
> color of the column header in a GTK TreeView, using a
> ListStore as the model?
Nope, I tried and tried. the Header lables, AFAICT, cannot be changed
from the standard colors. I'd be interested if a
63 matches
Mail list logo
