Hi All:
Can GTK+ control the menu popup direction ?? When I create a
popup menu and use the function gtk_menu_popup to show the menu, and the
menu alway pops from up to down. Is it possible to pop the menu from
down to up ?? I try to find solution for this from the Google search and
the
Can anyone shed some light on why the following API's are missing from 2.14.1 :
* gtk_font_selection_get_face_entry
* gtk_font_selection_get_family_entry
Both of these were removed in 2.13.7
* gtk_widget_get_allocation
Removed in 2.14.1 (that I know of)
*
On Wed, 2008-09-24 at 13:59 +0100, Matt Keenan wrote:
Can anyone shed some light on why the following API's are missing from 2.14.1
:
* gtk_font_selection_get_face_entry
* gtk_font_selection_get_family_entry
Both of these were removed in 2.13.7
*
Le Wed, 24 Sep 2008 16:16:20 +0800,
XiuHua Wu [EMAIL PROTECTED] a écrit :
Hi All:
Can GTK+ control the menu popup direction ?? When I create a
popup menu and use the function gtk_menu_popup to show the menu, and
the menu alway pops from up to down. Is it possible to pop the menu
from
Yes, I know it can use this function to determine the position of the
menu. But if the menu is dynamic, I mean the length is not fixed and can
be changed during the program running, so the menu position must be
calculated every time. If the menu can be dropped from down to up, and
it only
Le Thu, 25 Sep 2008 09:00:21 +0800,
XiuHua Wu [EMAIL PROTECTED] a écrit :
Yes, I know it can use this function to determine the position of the
menu. But if the menu is dynamic, I mean the length is not fixed and
can be changed during the program running, so the menu position must
be
On Tue, 2008-09-23 at 18:31 -0400, Morten Welinder wrote:
* Deprecate the H/V split and add orientation instead
+ mitch has a patch deprecating all the H/V classes
+ adds a constructor for base classes
+ defaults can be fixed
+ subclassing is easier
+ change orientation at runtime
+
I don't think the minutes reflect what was said in the meeting here.
My understanding was hat the H/V subclasses get deprecated as soon
as the code to enable flipping in their parent classes is in SVN.
If, say, gtk_hbox_new was to get deprecated and disappear in 3.x then
it would be
On Wed, 2008-09-24 at 11:23 -0400, Morten Welinder wrote:
I don't think the minutes reflect what was said in the meeting here.
My understanding was hat the H/V subclasses get deprecated as soon
as the code to enable flipping in their parent classes is in SVN.
If, say, gtk_hbox_new was to
Am Mittwoch, den 24.09.2008, 18:03 +0200 schrieb Xavier Bestel:
BTW where can I find a list of 2.90/3.0-deprecations ?
2.90 and 3.0 won't deprecate anything. Your list will be the list of
deprecated API shipped with 2.16.0.
Regards,
Sven
___
Le mercredi 24 septembre 2008 à 18:06 +0200, Sven Herzberg a écrit :
Am Mittwoch, den 24.09.2008, 18:03 +0200 schrieb Xavier Bestel:
BTW where can I find a list of 2.90/3.0-deprecations ?
2.90 and 3.0 won't deprecate anything. Your list will be the list of
deprecated API shipped with
2008/9/24 Michael Natterer [EMAIL PROTECTED]:
On Wed, 2008-09-24 at 11:23 -0400, Morten Welinder wrote:
I don't think the minutes reflect what was said in the meeting here.
My understanding was hat the H/V subclasses get deprecated as soon
as the code to enable flipping in their parent
Personally if i had the choice (but i'm not into all factors and standard
procedures and their motivations at Gtk+ in the past), i'd keep the API
calls of GtkVBox/HBox for a really long time, and (yes) certainly past 3.0,
and make them just be wrappers for the new orientation API.
In theory
How is this different from any other deprecated function that got
replaced by another one and will disappear in 3.0?
1. The number of uses of hbox and vbox is *huge*. Working around it
with an #ifdef or two is not going to work well. We're easily talking
hundreds of instances here for a
Can anyone shed some light on why the following API's were removed from
Gtk between 2.13.5 and 2.24.1 :
* gtk_font_selection_get_face_entry
* gtk_font_selection_get_family_entry
Both of these were removed in 2.13.7
* gtk_widget_get_allocation
Removed in 2.14.1
*
On Wed, Sep 24, 2008 at 12:12 AM, Emmanuele Bassi [EMAIL PROTECTED] wrote:
= minutes for the 2008-09-23 meeting =
* Deprecate the H/V split and add orientation instead
+ mitch has a patch deprecating all the H/V classes
+ adds a constructor for base classes
+ defaults can be fixed
+
Am Thu, 25 Sep 2008 02:20:35 +0300
schrieb Vlad Grecescu [EMAIL PROTECTED]:
On Wed, Sep 24, 2008 at 12:12 AM, Emmanuele Bassi [EMAIL PROTECTED]
wrote:
= minutes for the 2008-09-23 meeting =
* Deprecate the H/V split and add orientation instead
+ mitch has a patch deprecating all the H/V
Am Wed, 24 Sep 2008 22:43:32 +0100
schrieb Matt Keenan [EMAIL PROTECTED]:
Can anyone shed some light on why the following API's were removed
from Gtk between 2.13.5 and 2.24.1 :
* gtk_font_selection_get_face_entry
* gtk_font_selection_get_family_entry
Both of these were
The attached patch adds authentication support in the GTK+ CUPS backend.
For now it only works with authentication mechanisms that don't require
password prompting (in other words, GSSAPI).
Successfully tested against CUPS using GSSAPI.
Cheers,
Jelmer
--
Jelmer Vernooij [EMAIL PROTECTED] -
On Thu, 2008-09-25 at 02:42 +0200, Jelmer Vernooij wrote:
The attached patch adds authentication support in the GTK+ CUPS backend.
For now it only works with authentication mechanisms that don't require
password prompting (in other words, GSSAPI).
Successfully tested against CUPS using
20 matches
Mail list logo
