Re: [ADMIN] Looking for new list maintainer

[Dave Howorth]

On 2016-06-21 14:50, Leandro Pereira wrote:

On Tue, Jun 21, 2016 at 2:29 PM, Leandro Pereira 
wrote:


If you'd like to be the new maintainer please send me a private email, and
I'll list you as the administrator.



Emmanuele Bassi just manifested interest in maintaining the list, and I've
passed the token to him.


Thanks, Leandro. Thanks, Emmanuele.


Cheers,
Leandro

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

Re: Compiling for Windows [Was: argv revisited]

[Dave Howorth]

On 2016-05-03 16:57, Florian Pelz wrote:

I'd like to have one standard GTK+ installer for the GTK+ DLLs etc. that
can be downloaded and installed from other installers, so there is just
one GTK+ installed on Windows instead of one copy of perhaps different
versions of GTK+ for each application.


That's been a longstanding desire of many people. The other side of the 
argument of course is that all the applications have to be compatible 
with that particular version of the libraries, which has sometimes 
proven to be problematic even when the libraries ship with Windows. 
Expecting every application to be updated every time there is a library 
update is not realistic. It's not like a linux distro where the distro 
can update and recompile all the dependencies itself.

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

Re: Remote gtk3 app rendering issues

[Dave Howorth]

Sorry, ignore my message. Posted before brain was engaged. The OP is 
asking about something different, where I believe I understand the X 
mechanism but not how gtk3 uses it.


On 2016-04-21 10:30, Dave Howorth wrote:

On 2016-04-21 01:35, Daniel Kasak wrote:

Greetings all. I have a bizarre issue that makes me wonder if I
understand how remote X applications work ...

I'm running Sabayon Linux on my dev laptop. My work has a bunch of
Ubuntu 14.04 LTS servers. When I ssh into a server and run a gtk3 app,
it renders widgets in a horrible 3.1 style, and many icons are
missing.

But if I tar up /usr/share/themes/Ambiance on the server, and dump it
into my ~/.themes on my laptop, the widgets render in the 'Ambiance'
theme - but *only* if I *also* tell my local window manager (
Enlightenment ) to use the Ambiance theme. I usually use the Adwaita
theme. I see that Ubuntu 14.04 LTS doesn't have the Adwaita theme -
maybe it's too old for this?

What's going on here? I thought the X client did all the rendering,
and pushed pixmaps to the ( in this case, remote ) X server. But
clearly resources on my laptop are being used here.


You're correct that X clients are in control of the rendering. But
remember there are multiple X clients - in particular there is an X
client called the window manager, which is running on your laptop. Guess
what the window manager does? It draws the windows and their decorations.


Perhaps I'm approaching things incorrectly? What's the "recommended"
way of running remote ( gtk3 in particular ) apps and having them
render nicely - ie as they would if I was actually on the server I'm
ssh'd in to?


Sorry, can't speak to how gtk3 does things.


Dan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


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


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

Re: Remote gtk3 app rendering issues

[Dave Howorth]

On 2016-04-21 01:35, Daniel Kasak wrote:

Greetings all. I have a bizarre issue that makes me wonder if I
understand how remote X applications work ...

I'm running Sabayon Linux on my dev laptop. My work has a bunch of
Ubuntu 14.04 LTS servers. When I ssh into a server and run a gtk3 app,
it renders widgets in a horrible 3.1 style, and many icons are
missing.

But if I tar up /usr/share/themes/Ambiance on the server, and dump it
into my ~/.themes on my laptop, the widgets render in the 'Ambiance'
theme - but *only* if I *also* tell my local window manager (
Enlightenment ) to use the Ambiance theme. I usually use the Adwaita
theme. I see that Ubuntu 14.04 LTS doesn't have the Adwaita theme -
maybe it's too old for this?

What's going on here? I thought the X client did all the rendering,
and pushed pixmaps to the ( in this case, remote ) X server. But
clearly resources on my laptop are being used here.


You're correct that X clients are in control of the rendering. But 
remember there are multiple X clients - in particular there is an X 
client called the window manager, which is running on your laptop. Guess 
what the window manager does? It draws the windows and their decorations.



Perhaps I'm approaching things incorrectly? What's the "recommended"
way of running remote ( gtk3 in particular ) apps and having them
render nicely - ie as they would if I was actually on the server I'm
ssh'd in to?


Sorry, can't speak to how gtk3 does things.


Dan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


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

Re: Gtk+3 application Internationalization

[Dave Howorth]

On 2016-04-14 16:27, Emmanuele Bassi wrote:

On 14 April 2016 at 08:30, Ondrej Tuma  wrote:


because Stock Items are deprecated from Gtk+3.10, what can I use, if I
want to use gtk locales in my Application.


Use your own (localized) string.

Better yet, use readable strings that rely on the context of the
operation, instead of just random words that the tool kit itself has
no way to adapt to your case.


I don't know, if I understand it well, that I must translate all
strings in my application (copy from Stock Items) one more time to all
languages just like Gtk if I want to use them ?


It's hardly going to be an issue.


I don't understand. With the old method, I chose stock items and 
localisation was done automatically by the system, yes? As application 
author I didn't have to consider it.


How is localisation done in the new system? I've looked at

https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub

but I'm afraid I still don't understand.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help! Custom cell renderers blowing up ...

[Dave Howorth]

Dan Kasak wrote:
 On Fri, 2013-02-22 at 05:18 +, Dan Kasak wrote:
 
 Hi Torsten. Thanks, once again, for the reply.
 
 AHA! Removed some distro libraries and pulled in via cpan ... and it's
 FIXED!

In most distros at least, you shouldn't need to remove distro libraries
(assuming you mean perl modules installed from distro RPM/DEB). In fact,
it can be dangerous to do so since some system utilities rely on those
versions. If you just install libraries using cpan in addition to those
already present through your distro package manager, things will just
work. Perl has multiple search paths and they're set up to make this
magic happen.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: GTK Menu Window Type

[Dave Howorth]

BRAGA, Bruno wrote:
 Hi,
 
 I am trying to use an application written in Perl/GTK (volwheel -
 http://oliwer.net/b/volwheel.html), but I had some trouble to display the
 popup menu on my screen, because I am using i3wm as my window manager, and
 it is bringing the menu as a whole (top level) window instead of a popup.
 According to developers of i3wm, this happens because the window type is
 not properly set.

Does it obey the ICCCM WM_TRANSIENT_FOR property? (and is that set?)

 Like we have options to define the window type in Gtk2::Window-new($type),
 can we somehow set the window type for a Gtk2::Menu-new() ?
 
 In i3, all windows with type  dialog, utility, toolbar and splash windows
 are defined to be floating (displayed such as a popup on screen), and all
 others are displayed as a top level.

That seems a strange list, why wouldn't a popup-type window be displayed
as a popup?

 Is there any way to come around this problem?

Do you think the problem is in i3wm, the GTK libraries (perl or C?) or
the volwheel application?

What properties/hints etc are set on the menu window?
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Popup menu for Gtk2::Entry

[Dave Howorth]

Juergen Harms wrote:
 Hallo - I am new to this list, just discovering perl Gtk, trying to get
 educated by porting code from a perl Tk application.
 
 Question: How can I find the popup menu fo entry widgets (bound to the
 right button?) - a default menu exists, comes up like a charm.

I don't know how to do this, but I'll have a look later if nobody else
answers your question first.

 PS: finding documentation is a frustrating business (my dexterity in
 googling grows more rapidly than my knowledge about perl). Is there an
 activity around gtk-perl where the naivity of newby users can be made
 to contribute the documentation?

I believe the philosophy with the Perl Gtk2 docs was to not repeat
anything that is already documented in the C interface (to save both
initial effort and ongoing maintenance labour). So your basic strategy
is to pretend you are writing the program in C and figure out roughly
what your approach would need to be. Then go to the perl Gtk2 docs to
discover any specific points that differ. And probably repeat at least
once for detailed information.

You can improve on that strategy in a couple of ways:

- there are various tutorials and code examples. If you're lucky, you'll
find one that's relevant. There are links in the archive of this list.

- Python adopted a different documentation strategy. Their docs are
easier to comprehend, because they contain more of the material that is
the same in C. And their bindings are similar enough to the Perl
bindings that you can learn useful things by studying their documentation.

You should also be aware that the development focus has now moved to
Gtk3, which has a somewhat different approach, I believe. I haven't yet
used it myself, so you'd need to ask elsewhere for advice.

HTH, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: unset default row in a treeview (treesort)

[Dave Howorth]

Thomas Funk wrote:
 Hi to all,
 I try to set the active row in a treeview(treesort) to another row than 0. 
 This works but the row 0 is always highlighted (light).
 Here's my code:
 my $row_path = $theme_center_list_real_hash{$row_name}; # e.g 4:2
 my $tree_model = $tree_view_object-get_model();
 my $treeiter = $tree_model-get_iter_from_string($row_path);
 my $treepath = $tree_model-get_path ($treeiter);
 my $treeselection = $tree_view_object-get_selection();
 $treeselection-select_iter($treeiter);
 
 If I printout the path list with
 @paths = $treeselection-get_selected_rows;
 only the selected row I want is listed. So I guess the light higlighted row 
 is an old display state.
 
 How can I clear this state?
 After clicking to another row it will be cleared but at the beginning when 
 the program starts it looks unpleasantly.

It sounds like you perhaps aren't allowing the program to process
events? After you call select_iter how is control passed back to the
event loop?

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Displaying a popup before the main window

[Dave Howorth]

Nicolas Courtel wrote:
 Hello,
 
 As my program needs a few seconds to start, I would like to display a
 popup to tell the user that it's working.
 Looks pretty simple, but for some reason the popup shows up empty, and I
 can't figure out what I've done wrong.
 
 I would be grateful for any clue, here's a short example which shows the
 problem.

There are various possible ways. The main problem with your version is
that you didn't process the events that occur when you try to show the
splash screen. The version below is one way to do it:

 #!/usr/bin/perl -w
 
 use strict;
 use Gtk2 -init;
 
 my $window = Gtk2::Window-new;
 $window-set_title (My window);

# my $popup = Gtk2::MessageDialog-new ($window, 'destroy-with-parent',
# 'info',
#  'none', Please wait for 10
# seconds...);

my $splash = Gtk2::Label-new(Please wait for 10 seconds...);
$window-add($splash);
$window-show;
 $popup-show;

# Process the events so the show actually does something

Gtk2-main_iteration while Gtk2-events_pending;

# The sleep is only here because this is an example, right?
# You wouldn't do this in real-life

 sleep 10;

# The splash needs to be destroyed before you add the real content.
# Build real content in a main container widget then destroy the
# splash, then add the container to the window

 my $label = Gtk2::Label-new (Hello, world!);

$splash-destroy;

 $window-add ($label);

# $popup-destroy;

 $window-show_all;
 Gtk2-main;
 

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

Re: Displaying a popup before the main window

[Dave Howorth]

Ooops didn't copy the mods into the email properly. Add one more line...

Dave Howorth wrote:
 my $splash = Gtk2::Label-new(Please wait for 10 seconds...);
 $window-add($splash);
 $window-show;
 $popup-show;

$splash-show;

 # Process the events so the show actually does something
 
 Gtk2-main_iteration while Gtk2-events_pending;

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

Re: Displaying a popup before the main window

[Dave Howorth]

Emmanuele Bassi wrote:
 in this case, spinning the main loop is just masking the fact that
 you're blocking the main loop. the correct way to deal with this is *to
 stop blocking the main loop*.

We are discussing a splash screen that is shown during initialization
while the GUI is being constructed and before the main loop is reached.

You're proposing a complicated alternative mechanism and to what end,
I'm not sure. Perhaps if you gave a reference to a good explanation of
your rationale, instead of simply pouring scorn on people, it would be
more helpful.

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Displaying a popup before the main window

[Dave Howorth]

Emmanuele Bassi wrote:
 On Wed, 2010-09-15 at 11:45 +0100, Dave Howorth wrote:
 Emmanuele Bassi wrote:
 in this case, spinning the main loop is just masking the fact that
 you're blocking the main loop. the correct way to deal with this is *to
 stop blocking the main loop*.
 We are discussing a splash screen that is shown during initialization
 while the GUI is being constructed and before the main loop is reached.
 
 the premise is, in this case, irrelevant: you're blocking the main loop,
 spinning it is pointless and dangerous.

You haven't given a single example or description of what is dangerous.

 actually, by showing a splash screen you're *delaying* the start up of
 your application: don't use splash screens. it's no 1997 any more.
 
 if your application starts slowly, bring up the UI as soon as possible
 and fill it up with real data lazily;

What do you expect a user to want to do with a UI that's incapable of
doing anything because it has no data?

 using a splash screen is just
 papering over the issue that you're blocking the user because. wait,
 that's *exactly* like manually spinning the main loop! who would have
 thought.

Sorry, I have no idea what that means.

 You're proposing a complicated alternative mechanism and to what end,
 I'm not sure.
 
 my end is to ensure people write *correct* application code, and use the
 toolkit in the *correct* way.

So again, please provide a reference to a description of the *correct*
way.

  Perhaps if you gave a reference to a good explanation of
 your rationale, instead of simply pouring scorn on people, it would be
 more helpful.
 
 the rationale is: by spinning the main loop you're masking issues in
 your application. don't do that. I thought it was clear by the amount of
 scorn I used.

Again, you have not given any characterisation or example of what such
an issue might be. You're just blustering.

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: how to prevent standby during critical operations on linux

[Dave Howorth]

A. Walton wrote:
 On Tue, Apr 6, 2010 at 6:05 PM, frm francesco.monto...@gmail.com wrote:
 Just a few more questions about it:
 1) the page you linked seems to contain API docs for a generic language (not
 necessarily C/C++) nor it contains any info about which library/header files
 contain those APIs... how can I use it from a C/C++ program?
 
 It's the D-Bus api, as it says on the page.

I suspect the OP's question was more about the documentation
conventions, the language binding conventions and details and an overall
'map' of the documentation set.

At least, that's what I think, coming to that page with no prior
context. I can assume what the method signatures mean and what a 'D-Bus
API' might be for but it's hard to make use of the information on the
page without a lot of digging around and the worry I might not have
found some important details or background.

The page would be improved enormously for readers new to the subject by
a link or two to the top levels of the documentation. A quick google
suggests that links to these documents might be appropriate, but there
may be better choices:

http://dbus.freedesktop.org/doc/dbus-specification.html
http://live.gnome.org/SessionManagement/GnomeSession
http://library.gnome.org/devel/dbus-glib/unstable/index.html

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

Re: Custom TreeModel

[Dave Howorth]

Kevin Ryde wrote:

 Glib::Boxed is a generic wrapper mechanism for arbitrary C structures.
 
 A copy of the Glib::Boxed docs?  Shouldn't need to replicate it.
 Similar appears under Memory Handling in Gtk2::api too, which is a
 slightly tricky place to find it.  Perhaps the gory details should be
 under Glib::Boxed and cross references from elsewhere.

No! That was my draft of revised documentation *for* Glib::Boxed!

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Custom TreeModel

[Dave Howorth]

Kevin Ryde wrote:
 muppet sc...@asofyet.org writes:
 That passage found its way into the docs because of the discussion 
 starting here:
 
 Sounds like that was about the callback.  Perhaps something along the
  following lines,

Thanks for taking the time to write a new version. I'd like to suggest a
couple of changes but I'm still confused about the actual semantics
though, so I can only provide draft text for one of them.

 A Gtk2::TreePath is numeric coordinates of a possible node.  A path
  object can be converted into either an array of unsigned integers or
 a string.  The string form is a list of numbers separated by a colon.
  Each number refers to the offset at that level.  Thus path '0'
 refers to the first toplevel node and path '2:4' refers to the fifth
 child of the third node.

I prefer the original version of the paragraph above. It emphasises the
distinction between a path and an iter better to my eyes.

 By contrast, a Gtk2::TreeIter is like a pointer to a specific node in
 a specific model.  Iters are the primary way to access row data or 
 traverse a model.  A path is converted to an iter with 
 $model-get_iter.

I prefer the original separation into paragraphs and don't have any
problem with the original wording of the By contrast ... paragraph.

  An iterator is generally used only for a short 
 time and is valid only while the model rows are unchanged.  If any
 row is deleted, inserted or reordered then all existing iters on that
 model become invalid and attempting to use one may result in a crash.

I like the new mention of the consequences of using an invalid iter.

 Iters on models with iters-persist in its get_flags last longer
 though, they remain good for as long as its row exists.  (See 
 Gtk2::TreeRowReference for a long-lasting row ref which works in both
  cases.)

This is what I'm not clear about. Does iters-persist cause this change
or not? If it does then the text under Creating a Custom Tree Model/Tree
Iters also needs some text explaining what is required. If not then the
original warning about differences from gtk+ needs reinstating.

 Paths and iters are both boxed objects (see Glib::Boxed) and like 
 many such objects if you're passed one in a signal call or 
 $model-foreach then it's only good within that call and using it 
 later may cause a crash.  Copy with -copy if necessary
 (remembering the above iter validity rule too).

This is very important. Specifically, it should be stated in the
documentation for Glib::Boxed! Perhaps something like:

Glib::Boxed is a generic wrapper mechanism for arbitrary C structures.
For the most part you don't care about this as a Perl developer, but it
is important to know that all Glib::Boxed descendents can be copied with
the copy method. You must make a copy when you wish to save a boxed
object that was given to you inside a callback from a signal or iterator.

In the Tree Model docs. It is probably also worth stating The easiest
way to save a TreePath is to convert it to a string and save that:
$string = $treePath_object-to_string

HTH, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Custom TreeModel

[Dave Howorth]

Kevin Ryde wrote:
 Oh, if you set iters-persist per your first post then the iter has to be
 good for as long as the row exists.

Is that correct? It seems to contradict the docs:

http://gtk2-perl.sourceforge.net/doc/pod/Gtk2/TreeModel.html#DESCRIPTION

The iterators are generally used only for a short time, and their
behaviour is different to that suggested by the Gtk+ documentation. They
are not valid when the model is changed, even though get_flags returns
'iters-persist'. Iterators obtained within a GtkTreeModelForeachFunc are
also invalid after the foreach terminates. There may be other such
cases. In the foreach case, and perhaps others, a persistent iterator
may be obtained by copying it (see Glib::Boxed-copy).

I'm not clear if iters-persist has any effect for a TreeModel?

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Gtk2::Assistant and Button Access

[Dave Howorth]

I think the documentation should be included in the distribution.

The Catalyst notion of packaging the main docs in a separate
Catalyst::Manual distribution seems to work fairly well. CPAN can link
between distributions.

Just a thought,
Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Crash processing g_object_new arguments

[Dave Howorth]

David Nečas wrote:
 The real problem is `pointers are integers' from the dark times of C.

BCPL created many positive influences but this wasn't its finest
feature. At least as seen with the benefit of hindsight!

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

Re: Has anyone been able to force TreeView expander with no children?

[Dave Howorth]

Daniel B. Thurman wrote:
 David Nec(as yeti physics muni cz
 (1) The signal is called row-expanded.
 
 [Dan] Thank you!  But how did you find this signal?

 The problem I have is: how do I capture the signal when the
 row is expanded?  I posted a follow up on this and it seems
 that the key is row-has-child-toggled, but this does not
 seem to work:
 
 self.treeview.connect('row-has-child-toggled', self.on_row_activated)
 TypeError: gtk.TreeView object at 0xb7b9ab6c (GtkTreeView at
 0x8df5080): unknown signal name: row-has-child-toggled
 
 I have, however tried:
 self.treeview.connect('row-activated', self.on_row_activated)
 
 and this works, except that the row has to be mouse
 double-clicked, which is not what I want.
 
 I sure wish there is a Python-GTK code somewhere
 that I could peruse to resolve my many issues!

I don't use Python, I use Perl. But I sometimes use the Python docs.

You asked Dan how he found the signal. How did you find the one you were
using? That's an oblique question. What I really mean is that
'row-has-child-toggled' is a signal on the model, so why do you expect
it to work on the view?

Are you aware of these python docs:

http://www.pygtk.org/pygtk2reference/class-gtktreeview.html
http://www.pygtk.org/pygtk2reference/class-gtktreemodel.html

http://www.pygtk.org/pygtk2tutorial/
and specifically
http://www.pygtk.org/pygtk2tutorial/sec-TreeModelInterface.html#sec-TreeModelSignals
http://www.pygtk.org/pygtk2tutorial/sec-TreeViewSignals.html

There's also
http://scentric.net/tutorial/treeview-tutorial.html

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

Re: How to forbid people to change GtkCheckButton's status manually?

[Dave Howorth]

Edheldil wrote:
 Hi,
 since the checkbox is not interactive, you can as well get rid of it and
 replace it with an image or even with a simple label. No need to confuse
 user with an apparently non-working control.
 
 Edheldil
 
 
 donglongchao wrote:
 I want to use some GtkCheckButton to display some status in my app.But I 
 want to forbid my customer to change these checkbuttons' status(choosed or 
 not ) by their hands,and they can only be changed by my app itself according 
 to  some values,etc..I want to know how to do this.Will some one help 
 me?Thank you.

 And I do not know if I choosed the right widget to do this task.If not, will 
 some one tell me which one should be better? Thank you again.

I'm surprised nobody has mentioned gtk_widget_set_sensitive()

Cheers, Dave


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

Re: Gtk2::TreeView get_path_at_pos doesn't return array on Windows

[Dave Howorth]

Peter Juhasz wrote:
 (I was instructed on Perlmonks to post this problem here.)
 
 I'm writing a Gtk2-Perl app with a Gtk2::Ex::Simple::List (which is
 derived from TreeView, hence the title).
 
 I want to set up one of the columns in a special way, specifically, I
 want this column to hold values from a short list, and each click on a
 cell in this column should toggle the next value from the
 pre-specified list. Run the attached code for clarification.
 
 Obviously, for this I need to know which column did the user click into.

Thanks for the nice example, which works for me on Linux. I don't have a
 M$ box so can't help you with why it doesn't work there. But maybe
there's a neater other way. Have you tried:

 my ($path, $column) = $tslist-get_cursor;

instead of get_path_at_pos() ?

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Confused about $data=undef in API documentation

[Dave Howorth]

Joseph Thames wrote:
 Ok, now I understand. I think I was misled by most of the examples,
 which all seem to show callbacks statically the same as the
 Glade-specified menuitem names.

You understand perfectly how to write a patch for the docs so they are
clearer, then :)

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Stop alt-spacebar window menu

[Dave Howorth]

Bill Farmer wrote:
 I don't think it can be done without changing the window manager default
 key mapping, which apply to all apps. I can't find anything in the
 window and session manager functions part of the xlib documentation that
 says anything about key mapping. I've also tested a simple as possible X
 application with no Gtk in it at all, and it behaves just the same. So
 my problem  has nothing to do with  Gtk. But I didn't know that when I
 asked the question...

I think you're right. I think it's a general X question about how X
clients (a.k.a. applications) interact with the specific class of X
clients called window managers. I should have said that :)

So you may get a better answer on some X / W window manager list, but
the people on this list tend to be fairly knowledgeable so I was just
hoping I might prod somebody into remembering something.

My point (3) does hint there may be something in some API a normal X
client can use to change the window manager's key bindings. It might be
worth reading rdesktop's source.

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

Re: Stop alt-spacebar window menu

[Dave Howorth]

Brian J. Tarricone wrote:
 2.  Suggest that users disable conflicting key bindings or, if that's
 not possible, use a different WM that doesn't have a conflicting key
 binding (or is configurable).

 You can't.  The WM doesn't care what app is focused.  It'll eat the key
 regardless.
 
 And besides, even if you do find a solution for GNOME, what about people
 who run KDE?  Xfce?  LXDE?  *box?  Ratpoison?  ..

Bill's problem is interesting. It seems like a real reason to want to
use particular keys. And X11's motto is 'mechanism not policy' so I'd
persist in trying to find a solution for a while :)

I don't know the answer but I've found a few hints.

(1) a lot of window managers allow you to configure their keybindings
(e.g. kwin, xfwm, icewm) so maybe that is worth looking at.

(2) The ICCM says http://tronche.com/gui/x/icccm/sec-6.html#s-6.3
Window managers should ensure that they provide some mechanism for
their clients to receive events from *all* keys and all buttons (my
emphasis) so there's some hope that every window manager will allow
reconfiguration. The bad news is that they may all do it in different ways.

(3) there is a program called rdesktop that lists the following option
-K Do not override window manager key bindings. By default rdesktop
attempts to grab all keyboard input when it is in focus.
Which suggests there might be a way to do what you want.

(4) I found the following tantalising hint It is possible
to replace most window managers on the fly now with the −−replace
switch, which opens another possibility :)

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

Re: Is there anyone out there?

[Dave Howorth]

Cowley Harris wrote:
 I'm just pointing out that the sourceforge site has a ghost-town feel
 to it.  And as it turns up first on a google search, it could be
 off-putting to people who may be migrating from Perl-Tk who are
 evaluating the alternatives. I think as I have new eyes I'm going to
 see the stuff you may be oblivious too.

I'm just an occasional user and initially I had many of the same
reactions you did. But the group has been very helpful and now I've
climbed at least part way up the learning curve. Now you're subscribed
to the list you'll soon see the effort that is put into maintenance and
enhancements.

As well as the gtk-perl documentation, you will need to become familiar
with the C documentation, because a lot of the perl docs don't repeat
info that is already in the C docs. Start with the doc links at
http://www.gtk.org/.

Also very helpful is the Python documentation, e.g.
http://www.pygtk.org/pygtk2tutorial/ which is more extensive and
generally fairly easy to understand in a perl context.

 I'm also offering to help out with the documentation as per the Intro.

If there are broken links on the sourceforge site, I'm sure patches
would be welcome, or any other improvements you can suggest.

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: setuid / setgid

[Dave Howorth]

John Emmas wrote:
 It gives a link to a web page for more information
 (http://www.gtk.org/setuid.html) but to be honest, it doesn't explain the
 situation very well.  It doesn't explain what a setuid program is, nor
 why a program that was never previously a setuid program would suddenly
 become one.

That page seems to explain the issue quite well to me, but then I know
what setuid means and presumably you don't. But did you think to look up
the meaning of the word? The first hit in google is to a wikipedia
article that explains the basics. setuid is a longstanding 'well-known'
part of the unix/linux system security architecture so IMHO it's
unreasonable to ask that the web page should explain it.

When you understand the concept a little, you'll see that it has to do
with file permissions and user ids, so if you still have trouble then
posting the relevant details of your system will help anybody trying to
help you.

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

Re: non-gui usage of Gtk2::MozEmbed

[Dave Howorth]

Emmanuel Rodriguez wrote:
 Thete's also Mozilla::Mechanize
 (http://search.cpan.org/perldoc?Mozilla::Mechanize) that uses
 Gtk2::MozEmbed. But as you have found out it's impossible to use the
 Mozilla widget without having it added into a window.

Maybe it's possible to use a window on an Xvfb server? ...

http://www.x.org/archive/X11R6.8.2/doc/Xvfb.1.html

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Memory Leak

[Dave Howorth]

Richard Rosa wrote:
 Torsten Schoenfeld wrote: 
 
 I don't see the leak when running your example.  This suggests that it 
 might be
 a theme- or platform-specific issue.  What gtk+ theme and which platform 
 are you using?
 
  I'm running on Suse 10.3, KDE 3.5.  It looks like this may be a KDE problem.
 I brought up a Gnome session and the code no longer leaks... Not sure how
 to proceed from here, but at least I know that it is not a coding 
 issue.. 

Try suse 11.0 with the released and updated 3.5.x and 4.x versions from
the official repository. If the problem still occurs in either version,
report a bug at https://bugzilla.novell.com/index.cgi. It will get to
the KDE devs and be chased. 3.5 may be WONTFIX since its maintenence
only now, AFAIK.

Just a suggestion; I don't use KDE myself, and I don't have an 11.0 box
to try it :)

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Forking from Gtk

[Dave Howorth]

G Hasse wrote:
 But I realy NEED to create a longlived process (running for a week or
 month) and be able to quit the GUI whenever I like. The glib is
 just a wrapper - and i don't se the solution...
 
 I realy WANT to lose contact with the child process. And there
 is to mutch data from the GUI to pass it on the command line...

IMHO, in this circumstance, you still shouldn't have the GUI start the
long-lived process. You'll probably want some other mechanism to
[re]start the process in the event something goes wrong whilst it's
running. So set up the starting mechanism as a cron job or server
watchdog process. Then the GUI can just write the appropriate parameters
to a database or file or socket as you wish and the starting mechanism
will do the rest. No threads or forks in the GUI.

Cheers, Dave

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

Re: Locale definitions, dots and commas

[Dave Howorth]

Martin (OpenGeoMap) wrote:
 I am building an intermediate  unit system for engineeres in Gobject and 
 i hope publish this library soon.
 With this system you always work in lineal measures in meters (double), 
 and you can input others (inches, centimeters)
 
 input system - intermediate system -out system
 
 you can input in a entry for example (22m, 22 m, 220cm,...) and 
 internally you have a double always in meters.

How do you deal with precision? 22 m is not the same as 22.000 m

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

Re: Locale definitions, dots and commas

[Dave Howorth]

Martin (OpenGeoMap) wrote:

 Yes 22 m is the same as 22.000 m

No, they are not the same. The second one says that something is known
to within a mm. The first does not.

 PERL Regular expresions are great in C also, but better in perl and 
 Ruby  8-)
 To learn a little about regular expresion you need a PERL book:
 http://www.oreilly.com/catalog/regex/

Thanks but I have a few. I program in Perl (as well as C etc)

 Bad example.  22 can be expressed exactly in 2s complement.  3 cannot.

The issue is nothing to do with computer representation. Look up
'significant figures'.

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

Re: TreeIters again

[Dave Howorth]

muppet wrote:
 GtkTreeIter is designed to be very fast in C code, using stack
 allocation and short object lifetimes.  This makes binding GtkTreeIter
 to a dynamic language like perl rather, ahem, challenging, and
 Gtk2::TreeIter is not very natural in perl.

Hmm, I see messages on gtk-app-devel-list discussing problems people are
having in C, so I'm not sure I entirely buy this :)  I couldn't see how
to do this operation in C either - it's not like I found a hole in the
Perl binding.

 You can get a path from an iter, and you can convert a path to indices. 
 You can build a path from indices.  From the docs:

 my $selected_index =
 ($tree_store-get_path ($selected_iter)-get_indices)[-1];

Thanks! This is what I've done.

There are iters, paths and indices; all of which could potentially be
used by themselves to manipulate a tree, but it turns out you have to
use all three together. Let's just say some other tree manipulation APIs
are easier to use.

BTW, I quickly skimmed the Python docs. Did I misunderstand or have they
somehow merged iters and paths?

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

TreeIters again

[Dave Howorth]

I'm back to struggling with TreeIters again :(

This time, I'm trying to do something with a set of siblings. I have
some code that walks the siblings nicely:

for (my $iter = $tree_store-iter_children($parent);
$iter;
$iter = $tree_store-iter_next($iter)
)
{
# do something
}

But $parent isn't where I start. I actually start from one of the
siblings, which I want to treat specially. So my code actually looks
like this:

my $parent = $tree_store-iter_parent($selected_row_iter);

for (my $iter = $tree_store-iter_children($parent);
$iter;
$iter = $tree_store-iter_next($iter)
)
{
if ($iter == $selected_row_iter) {
# do special case
} else {
# do normal case
}
}

The problem is that $selected_row_iter is never equal to $iter. $iter is
a new TreeIter for every sibling.

rantTreeIters seem like a very badly thought out feature!/rant

I know I could make a TreePath from each iter and compare the paths, but
that seems slow since it involves iterated extra object creation etc.

I know I could use iter_nth_child() to iterate using an index, but I
haven't found a way to discover the index of the selected child.
Something like:

my $selected_index =
$tree_store-???child_index???($parent, $selected_iter);

my $n = $tree_store-iter_n_children($parent);

for (my $i = 0; $i  $n; $i++)
{
my $iter = $tree_store-iter_nth_child($parent, $i);
if ($i == $special_index)
...
}

And I know I should be able to iterate using TreePaths directly, but
when I try that, not only do I have to convert every path to an iter
(slow), but I haven't found the proper idiom. When I do this:

my $selected_path = $tree_store-get_path($selected_row_iter);
my $parent= $selected_path-copy-up;

for (my $path = $parent-copy-down;
$path;
$path-next
)
{
my $name = lc $tree_store-get($tree_store--get_iter($path), NAME);
if ($path-compare($selected_path) == 0) {
...
} else {
...
}
}

I get an error 'Can't call method copy without a package or object
reference' at the $path = $parent-copy. But $parent claims it is a
TreePath, which isa Glib::Boxed - parent $VAR1 = bless( do{\(my $o =
345348880)}, 'Gtk2::TreePath' );

So I'd welcome any suggestions as to how to iterate through the siblings
of a node in a TreeStore?

Thanks, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

getting setting colors

[Dave Howorth]

I want to temporarily change the background or foreground color in a
widget (TextBuffer or Entry), to highlight errors.

I've found gtk_widget_modify_bg, which looks like it will let me change
the background colour, but I can't see any way to return the color to
what it was previously. I suppose I ust be missing something obvious :(
Is there a getter for the background color that I'm not seeing?

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

Re: Treeview column width changed signal

[Dave Howorth]

Jeffrey Barish wrote:
 Gorshkov wrote:
 
 You don't have to set the widths again every time you show them. When
 the TreeView becomes hidden/not hidden or visible/not visible, it will
 have the same properties and values it had the last time it was visible.
 The ONLY time you have set those values is when you display/realize the
 TreeView for the first time - I do it in my initialization code when I
 first create the widget.
 
 I know this.  I am not sure what I wrote that gave you the impression that
 this is what I am trying to do.

I just reread the thread and what you wrote to give that impression is
quite clear to me. I suggest you do the same to review what you said and
to re-evaluate what people have suggested.

I'll offer one further suggestion:

In order to determine the column widths, first see if the treeview
exists and if it does, ask it. If it doesn't exist, read the widths from
a file.

Create and maintain the file by hooking the destroy and delete events as
Gorshkov suggested.

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

Re: Displaying a (simple) list of strings

[Dave Howorth]

asdf wrote:
 Hi,
 
 I am just getting started with GTK+ programming using C. And after having 
 spent a
 few hours going through the GTK+ 2.0 tutorial, I am having a hard time 
 understanding
 and writing code to display a bunch of strings in a List (TreeView) widget.

Have you read this one?
http://scentric.net/tutorial/treeview-tutorial.html

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

Re: Do TreeIters persist after foreach search ?

[Dave Howorth]

Torsten Schoenfeld wrote:
 On Thu, 2007-11-08 at 11:53 +, Dave Howorth wrote:
 
 I think there must be something I'm overlooking about iters. I have code
 which for testing I've simplified to the following:
 
 What works for me in Odot is storing a copy of the iterator:
 ...
   $match_iter = $iter-copy;

Thanks, Torsten. I've just checked with my test program and it works for
me too. I'm rewriting another way to get more efficiency, but I'll
remember about Glib::Boxed-copy now you've introduced me to it!


I've also noticed that there is some specific Gtk2-Perl documentation
about iterators in the Gtk2::TreeModel description. I think the text is
misleading as well as incomplete, especially since it differs from the
underlying gtk+ functionality. So I'd suggest a change. Presently it says:

 ... These iterators are the primary way of accessing a model and are
similar to the iterators used by Gtk2::TextBuffer. They are generally
used only for a short time, and are valid only as long as the model is
unchanged. The model interface defines a set of operations using them
for navigating the model.

How about something like:

 ... These iterators are the primary way of accessing a model and are
similar to the iterators used by Gtk2::TextBuffer. The model interface
defines a set of operations using them for navigating the model.

The iterators are generally used only for a short time, and their
behaviour is different to that suggested by the Gtk+ documentation. They
are not valid when the model is changed, even though get_flags returns
'iters-persist'. Iterators obtained within a GtkTreeModelForeachFunc are
also invalid after the foreach terminates. There may be other such
cases. In the foreach case, and perhaps others, a persistent iterator
may be obtained by copying it (see Glib::Boxed-copy)

Sorry it's not very elegant but I don't know enough to be definitive!

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Do TreeIters persist after foreach search ?

[Dave Howorth]

I'm trying to write a method that locates a particular node in a
Gtk2::TreeStore. I'm using the foreach method as the basis for walking
the tree to find the node, but I'm having trouble extracting the
resulting iter. I get errors like this:

  Gtk-CRITICAL **: gtk_tree_store_get_value: assertion `iter-stamp ==
GTK_TREE_STORE (tree_model)-stamp' failed

I think there must be something I'm overlooking about iters. I have code
which for testing I've simplified to the following:

my $match_iter;
$tree_store-foreach(
sub {
my ($tree_store, $path, $iter) = @_;

my $level = $tree_store-get($iter, LEVEL);
warn   tree_store=$tree_store, iter=$iter;\n;

$match_iter = $iter;
return TRUE;
});

warn search $tree_store = $match_iter;\n;
my $level = $tree_store-get($match_iter, LEVEL);

It prints

tree_store=Gtk2::TreeStore=HASH(0x8283970),
iter=Gtk2::TreeIter=SCALAR(0x43e28c48);
  search Gtk2::TreeStore=HASH(0x8283970) =
Gtk2::TreeIter=SCALAR(0x43e28c48);
  Gtk-CRITICAL **: gtk_tree_store_get_value: assertion `iter-stamp ==
GTK_TREE_STORE (tree_model)-stamp' failed at [[[ the second get ]]]

So the tree_store and the iter values seem to be the same but somehow
the stamp is different and I can't see why.

The gtk+ docs mention complications about the lifetime of iters but (a)
I don't think what I'm doing causes the model to emit any signals and
(b) the GtkTreeModelFlags include 'iters-persist' when I print them. The
docs say Additionally, some models guarantee that an iterator is valid
for as long as the node it refers to is valid (most notably the
GtkTreeStore ...

Any ideas what's happening, or better ways to find a node in the model?

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Do TreeIters persist after foreach search ?

[Dave Howorth]

Emmanuele Bassi wrote:
 On Thu, 2007-11-08 at 11:53 +, Dave Howorth wrote:
 
 Any ideas what's happening, or better ways to find a node in the model?
 
 use a Gtk2::TreePath instead, which is meant to keep pointing to a row
 in the model (regardless of the fact if that row exists or if the data
 has been changed):
 
   # inside the foreach():
   $match_path = $model-get_path($iter);

the sub is already given the path as an arg so that can be simplified:

$match_path = $path;

 and then:
 
   $iter = $model-get_iter($match_path); # always check retval

I was trying to avoid this because I think it must do a second tree walk
to reach the node? Which shouldn't be necessary.

But I've switched to this technique at the moment unless anybody can
suggest anything better.

At the moment the search is way too slow. I'm just about to profile it
to see whether I can fix it or whether I need to do my main tree
handling outside of the gtk tree model and just use the gtk model as a
display slave.

I guess another alternative might be to reimplement foreach's tree walk
myself which would lose the function call overhead and will probably
avoid whatever weirdness is messing with the stamp.

Thanks, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Do TreeIters persist after foreach search ?

[Dave Howorth]

muppet wrote:
 The iters are intended to be used on the stack in C, so for a foreach(), they
 would be destroyed before returning from the foreach() call.

I saw the sentence about allocation on the stack but then it's followed
by the specific 'guarantee that an iterator is valid for as long as the
node it refers to is valid'. We learn by experience!

 Instead, either store the $path or, better yet, the data from the row that you
 found, like this:

 snip code

 Alternatively, you could just call the i-found-it-action in the foreach
 callback when you find the row you want, and avoid the issue.

I'm trying this. I've basically inverted my algorithm so I can step
through the gtk tree once and search a hash containing the matching data.

 (I should've read the whole thread before replying...)

Thanks to you and Emmanuele for taking the time to help.

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Subclassing a Gtk2::TreeStore

[Dave Howorth]

Thanks Torsten and Scott. I've looked at it some more and I suspect I
have two separate problems in addition to my initial lack of
understanding :(

Torsten Schoenfeld wrote:
 I haven't tested it in a complete application, but this seems to work:
 
   package MyTreeStore;
 
   use Glib qw(TRUE FALSE);
   use Gtk2;
 
   use Glib::Object::Subclass
 'Gtk2::TreeStore',
   ;
 
   sub drag_data_received
   {
   my ($self, $dest_path, $selection_data) = @_;
   return $self-SUPER::drag_data_received ($dest_path, $selection_data);
   }
 
   1;
 
   package main;
 
   my $store = MyTreeStore-new (qw/Glib::String/);
   $store-drag_data_received (undef, undef);
 
 Note how drag_data_received is overridden simply how you'd override any
 other method in normal Perl code, and how the parent's
 drag_data_received is invoked.

That code compiles and starts to run for me too. Unfortunately, it's too
simple in two ways.


Firstly, my tree has more than one column and as soon as I change the
call to MyTreeStore-new to have more than one column, I get the error
again e.g.:

  my $tree_store   = MyTreeStore-new(qw/Glib::String Glib::Int/);

  type MyTreeStore does not support property 'Glib::String'

At least I now know that the error is caused by multiple args. Any idea
on how to make the constructor work for trees with multiple columns?
I'll keep experimenting.


Secondly, and potentially more serious, is related to Scott's comments:

muppet wrote:
 To be a little more explicit, this works because where you need it to
 be overridden is in your own code, where perl's method lookup can
 work normally.

I don't think my code is where I need it to be overridden. I don't have
any plans to call drag_data_received. It's called automatically by gtk+
as part of the treeview drag'n'drop mechanism. What I do want to do is
influence what it does. From what you say, I suspect I can't to this.

So before I waste more of everybody's time chasing something that's not
possible, I'd better explain the big picture and you can hopefully
suggest a better way to achieve my goal.

My application is a tree editor. All the branches are the same height
and nodes are typed according to their height (family, species etc).
Only rearrangements that keep nodes at the same height should be
permitted - you can't turn a species into a family, for example.

The treeview drag'n'drop does pretty much everything I need. In my
current code, I just call enable_model_drag_source and
enable_model_drag_dest and gtk+ does the rest. But that allows a node to
be dropped anywhere, so I need to find a hook somewhere that allows me
to either prevent the node being dropped or force the drop destination
to be the nearest node of the correct type. I favoured the latter
option, given the well-known pixel sensitivity of the interface, and
that's why I'm trying to override drag_data_received. But any other
solutions are more than welcome.


 Trying to override drag_data_received as a signal won't work, because
 it's not a signal.

Yes, that's why I was very surprised to see the suggestion in the
section 'OVERRIDING BASE METHODS' on the page
http://gtk2-perl.sourceforge.net/doc/pod/Glib/Object/Subclass.html. I
think it could use rewording but I'm not sure exactly what it's trying
to say. Is the section wrongly titled? Should it be something like
'OVERRIDING SIGNAL IMPLEMENTATIONS IN BASE CLASSES'?

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Subclassing a Gtk2::TreeStore

[Dave Howorth]

Torsten Schoenfeld wrote:
 I see.  Unfortunately, it doesn't seem to be possible to override just
 one interface method of some class (like row-drop-possible).  You have
 to implement the whole interface, and that means implementing a
 completely custom tree model.
 
 But I think you can achieve what you want by using Gtk2::Widget's d'n'd
 stuff.  For example:

snip code

Excellent! That works perfectly.

Thanks again,
Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Subclassing a Gtk2::TreeStore

[Dave Howorth]

Emmanuele Bassi wrote:
 in C, I would just subclass GtkListStore with:
 
 snip code
 
 which, as far as I can see from the code, is the case (usual disclaimer
 applies: I haven't tested it with real Perl code). internally, the
 TreeView widget will call gtk_tree_drag_source_row_draggable() which
 will call into the Perl bindings, which in turn will call the
 ROW_DRAGGABLE sub.
 
 this is, by the way, what I meant by override the override the
 Gtk2::TreeDragDest interface method above, in order to control whether
 the destination row is a valid drop point in the original mail.

I think I tried something like this, as I mentioned in
http://mail.gnome.org/archives/gtk-perl-list/2007-October/msg00059.html
but I got:

  GLib-GObject-WARNING **: cannot add interface type `GtkTreeDragDest'
to type `MyTreeStore', since type `MyTreeStore' already conforms to
interface

 I'd say that, if this doesn't work, it should be considered a bug of the
 Perl bindings, as the code works perfectly fine from C (I used it inside
 the GtkFileChooser default implementation for GTK+ 2.12). 

I don't know enough to know whether it's a bug or not. Torsten gave me
another solution that worked but I can imagine there are other
circumstances where being able to override a method would be useful.

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Subclassing a Gtk2::TreeStore

[Dave Howorth]

A while ago, I asked a question that received the answer below from
Emmanuele. I solved my problem at the time without having to subclass
anything but I'm now trying to override the drag_data_received method ...

Emmanuele Bassi wrote:
 On Tue, 2007-06-12 at 13:41 +0100, Dave Howorth wrote:
 
 I've seen mention of 'gtk_tree_drag_dest_row_drop_possible' and the Perl
 equivalent 'boolean = $drag_dest-row_drop_possible ($dest_path,
 $selection_data)', which looks like it might be related to what I want
 to do. But I can't find any description that tells me where it's
 implemented, how it's called or how to override it.
 
 you'll have to subclass a tree model implementation (like
 Gtk2::TreeStore or Gtk2::ListStore) and override the Gtk2::TreeDragDest
 interface method above, in order to control whether the destination row
 is a valid drop point.
 
 to know how to subclass and override a GInterface, see the
 Glib::Object::Subclass perldoc.

... so I've looked at the perldoc and have tried to subclass the
TreeStore but I haven't found the right incantations to be able to
override the drag_data_received method whilst inheriting all the other
behaviour of the TreeStore.

My [non-working] code looks like this:

package MyTreeStore;

use Glib::Object::Subclass
  'Gtk2::TreeStore',
#interfaces = [ 'Gtk2::TreeDragDest' ],
#signals = { drag_data_received = \_drag_data_received },
;

use Glib qw(TRUE FALSE);

sub DRAG_DATA_RECEIVED
{
my ($self, $dest_path, $selection_data) = @_;

warn DRAG_data_received($dest_path, $selection_data)\n;

return SUPER-drag_data_received ($dest_path, $selection_data);
}

sub _drag_data_received
{
my ($self, $dest_path, $selection_data) = @_;

warn _drag_data_received($dest_path, $selection_data)\n;

return TRUE;
return SUPER-drag_data_received ($dest_path, $selection_data);
}

1;


Like this, it says type MyTreeStore does not support property
'Glib::String' when I invoke MyTreeStore-new. In fact, it says this
even if I comment out both of the DRAG_DATA_RECEIVED and
_drag_data_received functions.

If I uncomment the interfaces line (suggested as needed by the
INTERFACES section of the Glib::Object::Subclass perldoc) it says
GLib-GObject-WARNING **: cannot add interface type `GtkTreeDragDest' to
type `MyTreeStore', since type `MyTreeStore' already conforms to
interface as well as the Glib::String problem.

If I uncomment the signals line (suggested by the OVERRIDING BASE
METHODS section) it says can't override class closure for unknown
signal drag_data_received, which doesn't really surprise me since
drag_data_received is a method rather than a signal.

Any hints gratefully received.

Thanks, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

detecting tree searches

[Dave Howorth]

My application takes actions when a different row is selected in a
TreeView (based on the TreeSelection changed signal). But I want to
distinguish those cases where the selection changes because the user is
typing in a search key. Is there any way to tell when a search is in
progress?

I've noticed the start-interactive-search signal but I haven't found
something to tell me when the search finishes.

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

focus

[Dave Howorth]

Is there an explanation of gtk's focus mechanism somewhere? That is, an
overview of how focus works, what the various focus-related signals mean
etc. I've googled but haven't found anything.

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

Re: start-editing signal?

[Dave Howorth]

Allin Cottrell wrote:
 On Mon, 24 Sep 2007, Kristian Rietveld wrote:
 
 On Fri, Sep 21, 2007 at 06:05:15PM -0400, Allin Cottrell wrote:
 My expectation: the unfinished edit will still be in place. 

 Actual behaviour: the bottles of coke cell is as it was before I 
 started; my edit-in-progress is gone.

 This may not be a bug as such, but I would like to know if there's 
 a way of preserving the state of the cell-editing process, in face 
 of the treeview window temporarily losing focus.
 The behavior you describe is indeed the current behavior in GTK+ 
 = 2.10 (and actually has some kind of history, but I won't 
 bother you with that ;).
 
 OK, thanks.  I've now updated myself on some of the history via 
 bugzilla.
 
 At this moment there is no code in GTK+ to automatically 
 preserve the value on focus out.  However, since there are 
 multiple different cases in which a focus-out should commit the 
 new value and also a lot of cases in which a focus-out should 
 *not* commit the new value, we are thinking of adding a property 
 to GtkCellRendererText which will control whether the input the 
 user has entered should be committed on focus-out or not.
 
 I haven't studied all the reports on this, but I have looked at 
 several of them.  I'll venture this opinion:
 
 The default behavior should just be to preserve state (the edit 
 remains in progress; it is neither automatically finalized nor 
 automatically destroyed).  Isn't this what users generally expect 
 of any GUI element that temporarily loses focus?  Surely loss of 
 focus should not, of itself and in general, DO anything, either 
 positive (commit the edit) or negative (lose the edit).

Absolutely! I run my window manager with a 'focus follows mouse' policy.
So a widget losing focus might mean that my cat has moved the mouse or
it might mean I've gone to another application to look for information,
perhaps to copy some text to paste into the widget. It might mean the
system has popped up a completely unrelated alert that has grabbed the
focus.

It seems a no-brainer that loss of focus should do *nothing* to the edit
state, nor should a subsequent regaining of focus. Explicit keyboard or
mouse actions on the widget itself should be used to change state, or
method invocations by associated widgets because of user actions on
them. That's fundamental for a sane user experience, I believe.

Yes, there are programming issues associated with abandoning a widget in
an editing-in-progress state but they just need careful coding.

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

Re: multiple changed events?

[Dave Howorth]

Thanks for the quick response, Emmanuele.

Emmanuele Bassi wrote:
 On Tue, 2007-09-25 at 11:32 +0100, Dave Howorth wrote:
 
 The changed callback is called twice from within set_text. The first
 time, the text is an empty string. The second time it is the value that
 was passed to set_text.
 
 the convention in gtk+ is that any changed signal is emitted at least
 once when something changes: there's no upper bound, just the lower
 one[1].

Hmm, I click on a button to make a bank transfer and the transfer
happens twice? I saw this issue once in an inter-bank transfer system.
The recipient said both transfers were correctly authorised and refused
to give the money (a million or two) back :(

 having said this, you can block the emission of a particular signal, or
 the calling of a specific callback. for instance:
 
   $entry-signal_handlers_block_by_func(\your_entry_callback, $data);
   $entry-set_text('foo');
   $entry-signal_handlers_unblock_by_func(\your_entry_callback, $data);
 
 will result in your callback not being invoked[2]; you can use this
 inside the callback of the other widget that controls the contents of
 the entry.

AFAICT, this would mean that my callback is not called at all. I need it
to be called once, so I've added my own semaphore around the call to
set_text and a check for the text widget's content being non-empty.
Fortunately I know that this text value can never be empty. But if the
text value could be empty I guess I'd have to set the semaphore before
calling set_text and clear it within the callback. And then I'd be
committed to a specific [buggy, IMHO] implementation of set_text.

 [1] I think there's a bug open, somewhere in bugzilla, for this specific
 instance (making a set_text() atomic); personally, I think it's merely a
 matter of taste: the ::changed signal convention is known and
 documented.

It's not documented where it's needed! (i.e. at
http://library.gnome.org/devel/gtk/unstable/GtkEditable.html#GtkEditable-changed
and/or
http://library.gnome.org/devel/gtk/unstable/GtkEntry.html#gtk-entry-set-text)
I don't understand how it can be viewed as a matter of taste? But I have
a workaround :)

Thanks again for the reply - at least I know it's not something I've
done wrong.

Thanks, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

GtkEntryCompletion popup size

[Dave Howorth]

I'm using a GtkEntryCompletion in popup-mode and controlling the list of
matches myself. I see that it displays up to 15 matches and if there are
more it adds a scroll bar to the popup window.

For my purposes it doesn't seem worthwhile to have a scroll bar. Is
there any way to control whether or when a scroll bar is added? Or is
there any way to discover the maximum number of rows that will be
visible in the popup? Or is it always guaranteed to be 15?

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

Re: Gtk2::ComboBoxEntry details

[Dave Howorth]

Chas Owens wrote:
 On 9/10/07, Dave Howorth [EMAIL PROTECTED] wrote:
 snip
 It works fine, except that certain strings, such as '' or '',
 don't appear in the popup list when they're part of the array.
 snip
 
 Could you provide a small, but complete, program that has this
 problem.  It will help us track down the issue.

Ah, thank you! It was brain failure on my part. That widget is not a
ComboBoxEntry at all, it's an Entry with an EntryCompletion and the
missing strings are filtered out by the completion system.

Thanks for waking me up. Sorry for the noise.

Any pointers about controlling or discovering the size of the popup list
would still be welcome but I guess that's almost certainly a question
for the gtk-app-devel-list.

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: GtkScale GtkHScale with multiple sliders and values?

[Dave Howorth]

[EMAIL PROTECTED] wrote:
 On 9/5/07, v4r4n [EMAIL PROTECTED] wrote:
 I've been trying to figure out how to create a GtkHScale that would let the
 user determine the beginning, middle, and/or end of a single data set.

Sounds like you're looking for something like the control used by the
Gimp's Colour Levels input level tool (Tools/Color Tools/Levels). If so,
it may be worth browsing the code :)

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

Re: tree view column sizing problem

[Dave Howorth]

Allin Cottrell wrote:
 I have a tree view with 3 columns, which sits within a scrolled 
 window.  
 
 The middle column contains what can be quite a lengthy string. 
 When the user opens the window in question, I'd like her to be 
 visually aware that the third column is there: the problem is that 
 with the columns autosized, the length of the middle string can 
 push the third column out of the visible zone (you have to scroll 
 horizontally to reach it).

I presume you can't just swap the second and third columns?

 The ideal solution, I think, would be (a) set the starting width 
 of the middle column to some reasonable maximum (when the window 
 is first opened), but then (b) allow the user to expand it to read 
 the full string if need be.

If the user can be satisfied with seeing one complete string at a time,
another option is to add a full-width label widget at the bottom of the
window showing the content of the second column of the currently
selected row. That avoids the need for the user to resize anything.

Or add tooltips to the column.

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

Re: overridding the theme in ~.gtkrc-2.0

[Dave Howorth]

Sergei Steshenko wrote:
 Another trick in Perl - if one wants to control the order in which 'use ...'
 statements are executed, 'eval' comes handy, i.e. one can write:
 
 something_to_be_done_first
 eval use Foo;;

No need for BEGIN blocks or tricks:

  require Foo;
  Foo-import;  # if necessary

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: dynamic combo entry

[Dave Howorth]

[posted back to list and trimmed]
Varun Khaneja wrote:
 On 8/7/07, Jim George [EMAIL PROTECTED] wrote:
 On 8/7/07, Dave Howorth [EMAIL PROTECTED] wrote:
 Jim George wrote:
 It may not be exactly what you want, but gtk_entry_set_completion might 
 help.
 It looks interesting. I've found the page in the reference manual and it
 says lots of things that sound intriguing but I'm having trouble
 grasping exactly what a GtkEntryCompletion can do :(  Are there any
 tutorials or examples to help me understand what it's capable of?

 Cheers, Dave

 Here's a quick example:
 ...

 Hi Jim,

 While I was reading through your reply to Dave, I said to myself, wow
 that's one really useful user interface practice. Great!

 What I thought of as an extension to this is: If the list is not huge
 to start with, maybe you could popup the names that match not just the
 beginning, but anywhere in the entire string.
 The question then rises, would it really be of any use? From my habits
 (or ability to remember and recall) it happens quite often that I
 remember the middle or end part of the name, but not the starting.

 There is a firefox extension that does something similar for typing
 URLs in the address box: myurlbar_a

 You could give it a thought, maybe.

I tried this with my half-million choice list :) It seemed it could be
useful if you can only vaguely remember what you're looking for, but
there was a practical problem for me. Because I'm truncating the
completion list, it sometimes happens that the desired choice never
appears in the list.

My list is of taxonomy entries, so for example suppose you want the
genus 'Homo'. It turns out that there are so many entries with 'homo'
somewhere in them that sort alphabetically before H that the term never
appeared. So in my case the strategy is no good.

I suppose I could have gone on to add a more clever ordering algorithm
but that seems overcomplicated. As it is, I still have to use a regex
because some of the names start with ' or ( or other bizarre characters
that people will never be able to guess. So I do allow the typed in
string to match either at the beginning or from the second character.

The bottom line is that the exact algorithm is likely to depend on the
details of the dataset and that it's fairly easy to add this type of
feature to your application.

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

Re: dynamic combo entry

[Dave Howorth]

Jim George wrote:
 On 8/7/07, Dave Howorth [EMAIL PROTECTED] wrote:
 Jim George wrote:
 It may not be exactly what you want, but gtk_entry_set_completion might 
 help.
 It looks interesting. I've found the page in the reference manual and it
 says lots of things that sound intriguing but I'm having trouble
 grasping exactly what a GtkEntryCompletion can do :(  Are there any
 tutorials or examples to help me understand what it's capable of?

 Cheers, Dave
 
 Here's a quick example:
 ...
 
 I use this when asking the user for a remote host name. I store a list
 of most-recently-used hosts, which populates the completion list. When
 the user types in a host name, if the first few characters match, a
 list pops up with all the remaining matches. Unfortunately, unlike a
 combo box, there's no way for the user to force this list to be shown
 (feature request?) In your case though (with 0.5e6 entries), this may
 actually be A Good Thing.

Thanks for the example, Jim. It does what I want and I've got a working
application now. What I'm doing is reloading the completion list as the
user types, so a short list of possibilities is visible at all times.

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

gtk-demo

[Dave Howorth]

Emmanuele Bassi wrote:
 gtk-demo includes working code for printing.
 you should have a look at it.

I just saw this and it was the first I'd heard of gtk-demo! So this is
just to point it out to anybody else like me.

It's probably installed on your system. I just had to type 'gtk-demo'
for it to run. It's well worth trying - thanks to the authors.

Also, I tried to find any mention of it on the gtk.org site. Even
googling 'gtk-demo site:gtk.org' doesn't produce a good hit. So it might
be worth adding to the FAQ and the documentation links, IMHO. And the
API reference etc etc :)

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

Re: dynamic combo entry

[Dave Howorth]

Jim George wrote:
 It may not be exactly what you want, but gtk_entry_set_completion might help.

It looks interesting. I've found the page in the reference manual and it
says lots of things that sound intriguing but I'm having trouble
grasping exactly what a GtkEntryCompletion can do :(  Are there any
tutorials or examples to help me understand what it's capable of?

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

Re: GTK STOCK ascending and descending

[Dave Howorth]

Alvis Koon wrote:
 Just wonder, why the GTK stock item icon of A-Z ascending and
 descending are displayed with blue and red arrows respectively?
 
 In my opinion, it will give the user a sense of activation for turning red.
 When turning blue, it looks as if deactivated.
 Actually they can both activated in both sense.

Stock prices in the London market are traditionally shown with blue for
upticks and red for downticks. Some other markets use green for the
upticks. There's a potential difficulty with using green because of
red-green colour blindness, though it doesn't seem to cause much problem
in practice.

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

Re: Not show selection of a tree view column

[Dave Howorth]

Peter Clifton wrote:
 I think a brand new widget might be needed - one which has a more
 table like rendering model.

I presume a GtkTable isn't table-like enough :)

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

Re: drag-data-received signal not being emitted

[Dave Howorth]

Chris Morrison wrote:
 On Wed, 2007-06-27 at 10:43 +0100, Dave Howorth wrote:
 I wrote:
 In particular, I believe you will also need to call
 gtk_tree_view_enable_model_drag_dest and/or
 gtk_tree_view_enable_model_drag_dest on the tree_view.
 Oops. Second one should be gtk_tree_view_enable_model_drag_source of course.

 I tried using gtk_tree_view_enable_model_drag_dest() on my tree view and
 it caused some really strange stuff to happen:

Odd, I've just had a good experience with it. I looked at the code that
implements gtk_tree_view_set_reorderable and saw that it calls the two
functions I mentioned. So it's a layered API but that's helpfully not
mentioned in the doc. Anyway, once I realized that, it was obvious that
I needed to replace my call to set_reorderable with my calls to
enable_model_drag_dest and enable_model_drag_source, rather than call
them in addition to it. It was also obvious that I needed to make sure
that I used the same arguments that it did so that the whole built-in
drag'n'drop mechanism kept working. Except I needed to change the one
argument that I wanted different behaviour for.

Now I can drag nodes from one view of the tree and drop them on another
view. Eliminates dragging/scrolling across thousands of nodes.

I'm using the Perl bindings, so my actual working code looks like this:

# The target entry must match that used by
# gtk_tree_view_set_reorderable in order for the built-in
# drag'n'drop support to keep working
# Except I use 'same-app' instead of 'same-widget'
#
my $target_entry = {
target  = 'GTK_TREE_MODEL_ROW',
flags   = ['same-app'],# Gtk2::TargetFlags
info= 0,
};

# Alternatively:
#my $target_entry = [ 'GTK_TREE_MODEL_ROW', 'same-app', 0 ];

$tree_view-enable_model_drag_dest(
['move'],
$target_entry,
);

$tree_view-enable_model_drag_source(
'button1-mask', # $start_button_mask,
['move'],
$target_entry,
);

 I got a segmentation fault when ever I tried to access the GList of
 targets in drag_context-targets in my drag_drop handler.
 
 If I returned FALSE from my drag_drop handler (i.e. to indicate the drop
 was not over a valid area of the widget) the drag-data-received signal
 was emitted but then I got a GTK critical assertion failed error.
 
 I think I might give up on the GtkTreeView and use a GtkIconView widget
 instead.

Not an option for me, since I'm playing with trees. I'd have to abandon
gtk altogether and move to another widget set, and probably language.
Swing, anybody? :)

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

Re: How to determine *actual* visible region of a window?

[Dave Howorth]

Gaurav Jain wrote:
 For the purpose of my application, I need to programmatically
 determine the actual 'exposed' region of a gdk window.  The exposed
 region should not include any obscured regions of the window.  For
 example, if there's some external window in front of my application's
 window, then the exposed region should not include the area obscured
 by that external window, but should include all other area that's
 visible.
 
 I tried using the API gdk_drawable_get_visible_region() but this
 doesn't exclude the obscured regions, so it's not of my use.
 
 Does somebody know of any suitable API that I can use to achieve what
 I want?  Or is there a method that somebody could suggest that I could
 use to calculate this region?

I'm pretty much a beginner with gtk but I do know a bit about X and you
haven't had an answer, so here's what I understand:

What is currently exposed is dynamic, of course, so it's event driven. I
believe you need to get the GdkEventExpose structure from a GdkEvent of
type GDK_EXPOSE and then look at the GdkRegion structure within it,
which contains the information you're looking for.

You'll need to enable such events on your window. You can also cause
such an event any time you want by calling queue_redraw.

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

Re: drag-data-received signal not being emitted

[Dave Howorth]

Chris Morrison wrote:
 Hi all,
 
 I am trying to write a GTK/GNOME application. It has a main window with
 GtkTreeView control on to which you can drag and drop files from
 Nautilus.
 
 The code I have used to set up the widgets is:

snip

 However, although the drag_drop signal is being received OK the
 drag_data_received signal is not being emitted at all. I have scoured
 the GTK documentation and Google but can find nothing on this.
 
 Any pointers would be appreciated.

I'm also trying to make drag-and-drop work in a tree and not finding
much in the docs. The best docs I've found so far are for the Python
bindings. Try:

http://www.pygtk.org/pygtk2tutorial/sec-TreeViewDragAndDrop.html
http://faq.pygtk.org/index.py?req=showfile=faq13.033.htp
http://faq.pygtk.org/index.py?req=showfile=faq13.034.htp

In particular, I believe you will also need to call
gtk_tree_view_enable_model_drag_dest and/or
gtk_tree_view_enable_model_drag_dest on the tree_view.

That said, I haven't managed to make it all work yet, so I'd be very
interested to see any working code - in my case for a tree rather than a
list.

Cheers, Dave

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

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

Re: drag-data-received signal not being emitted

[Dave Howorth]

I wrote:
 In particular, I believe you will also need to call
 gtk_tree_view_enable_model_drag_dest and/or
 gtk_tree_view_enable_model_drag_dest on the tree_view.

Oops. Second one should be gtk_tree_view_enable_model_drag_source of course.

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

Re: drag-data-received signal not being emitted

[Dave Howorth]

I wrote:
 I'm also trying to make drag-and-drop work in a tree and not finding
 much in the docs. The best docs I've found so far are for the Python
 bindings.

Murphy's alive and well. Just twenty minutes later and my words are
wrong :) I've just found this site:

http://www.codase.com/search/call?name=gtk_tree_view_enable_model_drag_sourceowner=lang=*project=search=Searchtype=parameters=nparams=-1obj=constant=

I'm hopeful it might have some interesting links.

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

Re: moving nodes in a tree

[Dave Howorth]

Roderich Schupp wrote:
 On 6/22/07, Dave Howorth [EMAIL PROTECTED] wrote:
 I'm trying to use $tree_store-move_after ($iter, $position) and
 $tree_store-move_before ($iter, $position) and am getting errors like
 this:  Gtk-WARNING **: Given children are not in the same level
 
 Looking at the Gtk sources, AFAICT they check not only for the
 same level, but that $iter and $position are actually siblings.

Yes, I had the same opinion, so I did a fresh install on a new Suse 10.2
system (there were some install problems I'll document separately):

Module version 1.144
Built for gtk+ 2.10.6
Running with gtk+ 2.10.6

With that version of gtk+, I was able to make move_after work. However,
what it does is move *just* the iter node. It doesn't move its children.
So the semantics are what I would expect of move_after in a ListStore,
not a TreeStore. Which is a royal pain.

I haven't yet had time to try my drag-and-drop code on the newer gtk+.

It seems like the major problems are in the gtk+ library, not in the
Gtk2 perl module. So I'll join the gtk-app-devel-list and see if anybody
there has some working code I can use as an example.

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Gtk2 fails install tests

[Dave Howorth]

As mentioned, I just installed Gtk2 1.144 on a Suse 10.2 AMD64 system
and I had install problems.

The GtkFileChooserButton.t, FileChooserDialog.t and
GtkFileChooserWidget.t tests just hung. I had to CTRL-C.

GtkIconTheme.t failed test 1.

Library versions are:
Module version 1.144
Built for gtk+ 2.10.6
Running with gtk+ 2.10.6

Full details are on rt.cpan:
http://rt.cpan.org//Ticket/Display.html?id=27724

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

moving nodes in a tree

[Dave Howorth]

I'm trying to use $tree_store-move_after ($iter, $position) and
$tree_store-move_before ($iter, $position) and am getting errors like
this:  Gtk-WARNING **: Given children are not in the same level

but I've called $tree_store-iter_depth ($iter) on both arguments
immediately before calling the move methods and I get the same numerical
result for both. i.e.

$model-iter_depth($source_iter) = 4
$model-iter_depth($destination_iter) = 4
$model-move_after($source_iter, $destination_iter)
  = Gtk-WARNING **: Given children are not in the same level

Am I misunderstanding the docs, or is there some other gotcha?

Module version 1.144
Built for gtk+ 2.6.4
Running with gtk+ 2.6.4

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: moving nodes in a tree

[Dave Howorth]

As I wasn't getting anywhere using move_before/after I decided to try
using the drag/drop interface instead. Sadly I'm not having much luck
there either. I write:

  my $source_path = $model-get_path($source_iter);
  my $draggable = $model-row_draggable($source_path);
  my $selection_data = $model-drag_data_get($source_path);

  warn source_path=.$source_path-to_string.\n;
  warn draggable=$draggable\n;
  warn selection_data=$selection_data\n;

and I get:

  source_path=0:0:0:1:0
  draggable=1
  Use of uninitialized value in concatenation (.) or string at
  ./scop-tree-editor.pl line 768.
  selection_data=

What am I doing wrong there?

$model isa TreeStore and the view is showing well-defined data on screen
and other code can access the row data successfully with get().


BTW, further to my previous mail:
 I'm trying to use $tree_store-move_after ($iter, $position) and
 $tree_store-move_before ($iter, $position)

I've also noticed that the Perl interface won't let me have $position be
undef, which is documented as OK in the C interface (NONE) and the
Python interface (None).

I haven't managed to find any examples for any of these features.

Cheers, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: trees - newbie question

[Dave Howorth]

muppet wrote:
 I went to that project and noticed it all seems a few years old. I
 tried to install Gtk2::Ex::Simple::Tree but it fails its tests. I
 forced the install and ran the example program. It runs but the OK
 button callback is buggy (using an unimplemented method). I changed
 the example to make one of the columns editable and discovered that
 the change doesn't persist (the widget is editable but reverts to its
 previous text).
 
 What versions of everything are you using?  Specifically, what versions
 of gtk+, Gtk2, and Gtk2::Ex?  Which unit tests failed?  For
 Gtk2::Ex::Simple::Tree, did you also install Gtk2::Ex::Simple::List?

There's more detail in my bug report on rt.cpan. I'm not sure I put all
the versions there: gtk2 is 2.6.4-6.7 (Suse pkg), Gtk2 is 1.144,
Gtk2::Ex is 0.50. The unit test fail and cause is as reported later on
this list by Roderich Schupp. I had installed Gtk2::Ex::Simple::List by
that time, because Tree fails to install otherwise :(  I put a separate
bug report on RT for that.


 There are more examples of using Gtk2::Tree* in the Gtk2 source under
 examples/ and demo/, and other programs available on the web.  You can
 also try the Gtk+ 2.0 Tree View Tutorial, linked from
 http://gtk2-perl.sourceforge.net/links/ .

I'd found some of those and have moved on to using TreeStore and
TreeView directly now. My initial program seems to be working pretty
well. I found one little oddity. My code for the callbacks for my expand
and collapse buttons looks like this:

my $xa_button = Gtk2::Button-new ('Expand All');
$bbox-pack_start($xa_button, FALSE, TRUE, 0);
$xa_button-signal_connect(clicked =
sub {
$tree_view-expand_all;
$tree_view-queue_draw; # doesn't redraw automatically
}
);

my $ca_button = Gtk2::Button-new ('Collapse All');
$bbox-pack_start($ca_button, FALSE, TRUE, 0);
$ca_button-signal_connect(clicked = sub { $tree_view-collapse_all });

The code for collapse is what I'd expect, but I had to add an extra line
to expand because it doesn't redraw the tree. I don't know whether I'm
missing something?


Thanks again,
Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: trees - newbie question

[Dave Howorth]

Emmanuele Bassi wrote:
 it might be a bug in gtk+ itself - the version of the C library you're
 using is pretty ancient[1]: the latest stable release is gtk+ 2.10.12,
 and we're rolling gtk+ 2.11 snapshots in order to release 2.12.0 next
 month or so.

Yeah, I'm still on Suse 9.3 but I'll likely be moving to 10.2 soon.

Thanks, Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

trees - newbie question

[Dave Howorth]

Hi,

I'm just starting trying to use gtk2 and gtk-perl. I'm particularly
interested in trees - I need a GUI for displaying and editing them. I
have some initial questions and hope somebody can point me in the right
direction.

In taking baby steps, I found Gtk2::SimpleList and built a test program
with it that worked :) I noticed that in its POD it says: Note:
Gtk2::SimpleList is deprecated in favor of Gtk2::Ex::Simple::List, part
of the Gtk2-Perl-Ex project at http://gtk2-perl-ex.sf.net;

I went to that project and noticed it all seems a few years old. I tried
to install Gtk2::Ex::Simple::Tree but it fails its tests. I forced the
install and ran the example program. It runs but the OK button callback
is buggy (using an unimplemented method). I changed the example to make
one of the columns editable and discovered that the change doesn't
persist (the widget is editable but reverts to its previous text).

So my first question is whether this module is usable/supported? Or are
there other examples using the Gtk2::Tree* modules?

I couldn't find any mailing list or forums for Gtk2-Perl-Ex, so is this
the right place to ask such questions? I tried to search the archives
for this list http://mail.gnome.org/mailman/search?... but couldn't
persuade it to give me any results. Is there another archive anywhere?

Thanks and regards,
Dave
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list