Use "space" for PageDown in TextView
Hi, I'm trying to write a simple text reading application with the TextView widget. As I am only doing reading I would like to rebind the space bar to do page down. But I can't get it to work. Here's what I did (in Python): # The following code is taken from # http://libre2.adacore.com/viewvc/trunk/gps/share/plug-ins/text_utils.py?view=markup&pathrev=131464 # and shows how to override key bindings. SPACE=32 BACKSPACE=65288 def override (key, modifier, movement, step, select): gtk.binding_entry_remove (gtk.TextView, key, modifier) gtk.binding_entry_add_signal (gtk.TextView, key, modifier, "move_cursor", gobject.TYPE_ENUM, movement, gobject.TYPE_INT, step, gobject.TYPE_BOOLEAN, select) def override_key_bindings (select): """Override the default TextView keybinding to either always force the extension the selection, or not""" override (SPACE,0, gtk.MOVEMENT_PAGES, 1, select) override (BACKSPACE,0, gtk.MOVEMENT_PAGES, -1, select) : tv = gtk.TextView() tv.set_editable(False) tv.set_cursor_visible(False) override_key_bindings(select=False) What seems to happen is that in addition to my SPACE binding another binding for space is being triggered. If I e.g. select part of the text in the widget and press SPACE, then the widget is scrolled such that the selected text is visible. So the question seems to be why does binding_entry_remove() not clear the default binding for space? Thanks! Dov ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkAssistant get nth page and GtkAssistant get current page APIs
2010/2/16 dheeraj reddy : > Hello > > I am facing problems using these APIs. on x11 > > 1) gtk_assistant_get_nth_page (). > it is given to pass -1 to get the last page. > but when tried it returns NULL. Bug reported here: https://bugzilla.gnome.org/show_bug.cgi?id=610141 > 2) gtk_assistant_set_current_page (). > it is given "If negative, the last page will be used." > but when negative page_num is passed the application crashes. Bug reported here: https://bugzilla.gnome.org/show_bug.cgi?id=610184 Thanks to Tadej for the reports Regards -- Javier Jardón Cabezas ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Ed James wrote: Joost, and others, I tried learning to use gtk, gdk, cairo, pango, etc several years ago and was frustrated by the difficulty in getting good docs, sample code, etc. Even worse was finding that "constant change" meant me having to rewrite code fairly often. Note that I'm an "old guy" who has written code for a living since I was a "young guy". But this has been the most difficult venue in which I've tried to work. I feel and share your pain in producing something of quality and lasting value. I know it can be done, but I pretty much work alone, and it's not easy. I switched to writing my own set of "widgets" in C++ which more or less look and act somewhat like Java's AWT, but nowhere near as powerful yet. I've got simple projects like a telnet client working, but I feel like I'm mining gold with a fork. My one big question to this list is (and no disrespect is meant), is there a elist similar to this one dedicated to Xlib programming? This list does have many very talented people, some of whom I'm in awe of. But I'm veering into a different direction and just need pointer towards that direction. ... xorg would be as close as any: xorg mailing list x...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Joost, and others, I tried learning to use gtk, gdk, cairo, pango, etc several years ago and was frustrated by the difficulty in getting good docs, sample code, etc. Even worse was finding that "constant change" meant me having to rewrite code fairly often. Note that I'm an "old guy" who has written code for a living since I was a "young guy". But this has been the most difficult venue in which I've tried to work. I feel and share your pain in producing something of quality and lasting value. I know it can be done, but I pretty much work alone, and it's not easy. I switched to writing my own set of "widgets" in C++ which more or less look and act somewhat like Java's AWT, but nowhere near as powerful yet. I've got simple projects like a telnet client working, but I feel like I'm mining gold with a fork. My one big question to this list is (and no disrespect is meant), is there a elist similar to this one dedicated to Xlib programming? This list does have many very talented people, some of whom I'm in awe of. But I'm veering into a different direction and just need pointer towards that direction. adTHANKSvance, Ed James On Wed, Feb 17, 2010 at 7:06 AM, Joost <1...@depikt.net> wrote: ... > own use. Working on my pygtk alternative depikt i learned that the promise > of easy interfacing with other languages (than C) is not empty. Then there > is gdk.Pixbuf and the integration of the well-designed pango and cairo. The > latter must have been a bit painful for the authors of the > gimp-tk - many thanks for that ! And thanks for the introduction to > widget construction. ...But the way thereto is nearly not documented... ... > During 3 years the documentation of gtk and gtk itself has never ceased to > cause this kind of pain. It is my fourth GUI-builder - and what is in the > tutorial ... ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
This here (the middle paragraph had been cut by a bug anywhere - it is in the version in my "Sent" folder) And i had found it somewhere on library.gnome.org - yes it is documented. But not at the prominent place, where it has to. This must be in one of the first paragraphs on .rc files everywhere. gtk authors will have had reasons for this ideosyncratic behavior of "widget". >From the first look it appears as nothing as another weakness - and that is, what i want to state as the second main point here: The documentation must be more honest to be well usable. These days i begin to make the User Manual for my commercial OKamba. I will cut off any try of pseudo-objectivity there and use a lot of "i"s (hopefully not too penetrant) using it for advertisement with the same move. But i will speak of more than one weakness of OKamba there - and prevent useless searching of the users so. The gtk docs - without any need - do so nowhere :( That is a sure way to loose the battle against QT. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Remarks on gtk docs
Hello,
this will be a long text. Parts of it have been circulated in my brain since
many months - i must do this. Please keep in mind, that i do not want
to offend anyone, my username "viciousdog" on sourceforge is nothing else
than a warning.
python/gtk/sqlite has been chosen as the ("virtualized") poor man's computer
by OLPC. I learned that after i had chosen this platform myself.
Continuing to read this, some of you might want to respond: "Then write
documentation yourself !!" - but i cannot. Living in a country, where a labour
politician has reintroduced forced labor recently i really have no time for
that.
I'd really like to write 10-20 pages about rc syntax, but what will come
below must be enough for the moment.
I will continue to write for this platform and make improvals of it for my
own use. Working on my pygtk alternative depikt i learned that the promise
of easy interfacing with other languages (than C) is not empty. Then there
is gdk.Pixbuf and the integration of the well-designed pango and cairo. The
latter must have been a bit painful for the authors of the
gimp-tk - many thanks for that ! And thanks for the introduction to
widget construction.
But that is all, what is really good in gtk.
Beginning my work on that software, which helped me to survive as an
intermediary internet dealer and beginning to use gtk i searched border-width.
>From the promise of high-quality-surfaces i was sure to find all what
tcl's TK - designated as "poor" by many programmers - has too.
You know, what followed. I learned that border-width means margin-width
with gtk, but that was of course no reason to continue searching. The
inevitable result: Hours of senseless pain. I am probaly fairly dumb
(i've met really better brains in my life playing bridge for example) -
on the other hand i am someone capable of learning Python's infamous
C-.API and to make depikt.
Yes, you can make high-quality-surfaces with gtk. You can determine every
pixel of your widget, if you want. But the way thereto is nearly not documented
at all. And the standard equipment is leading to surfaces as gnumeric has -
reminding me at GEM on the Atari ST.
During 3 years the documentation of gtk and gtk itself has never ceased to cause
this kind of pain. It is my fourth GUI-builder - and what is in the tutorial is
100%
useless in such a situation. No word about the style sharing, no word about the
needed full path to a widget's name in rc files, (probably) no word about
property-notify events, no word about what "Style properties" in the
references mean ... These thousands of pages have caused a lot of work on
your side - with about 100 good pages they were as useful as they could and
should be as the result of so much work
Only last week i learned that the "GtkEntry::cursor-color" in
GtkEntry::cursor-color = "DarkGrey"
is necessary - or is it not ? Again in a session fighting rc syntax with pain.
No chance at all to get to fluid writing with this beasty material. That comes
absolutely unexpected, after all we will link the style, where it is in, to an
entry
(and we absolutely should, when we want to produce well maintainable
software) thus it looks redundant on the first view.
What i had to learn in November under pains also is, that you have to
write the full path to the widget down in lines like:
widget "OKambaDialog.outer_bd.inner_bd" style
"st_dialog_inset"
"OKambaDialog" is necessary here - again deviating from what
contemporary programmers know from CSS's id versus class.
And if someone is prepared to this difference to class, he would
probably expect this whole path with "class", not with "widget".
And i had found it somewhere on library.gnome.org - yes it is documented.
But not at the prominent place, where it has to. This must be in one
of the first paragraphs on .rc files everywhere.
gtk authors will have had reasons for this ideosyncratic behavior of "widget".
>From the first look it appears as nothing as another weakness - and
that is, what i want to state as the second main point here: The documentation
must be more honest to be well usable. These days i begin to make
the User Manual for my commercial OKamba. I will cut off any try of
pseudo-objectivity there and use a lot of "i"s (hopefully not too penetrant)
using it for advertisement with the same move. But i will speak of more than one
weakness of OKamba there - and prevent useless searching of the users so.
The gtk docs - without any need - do so nowhere :(
That is a sure way to loose the battle against QT.
Yes, still i will continue to work with gtk. Here is what i wrote on depikt.net:
"""
With much more time i'd very like to make a simplified python-connected gtk,
dismissing the outdated painting methods of gdk (since some years obsoleted by
cairo inside gdk), some outdated features in imitation of X11 (as ... pixmaps),
the styles sharing, properties at all, and would let it work with python
classes
instead of glib. But that wi
