Re: gtk_entry_new and accented chars
Luiz Rafael Culik Guimaraes-4 wrote:
Dear Friends
I have an small app with one gtk_entry_new with an handle to my user
defined key_press_event
but i cannot get the accented char from latin 1 code page on entry
here an part of my key handler
here is the routine for key_press_event
#define WM_MOVE 3
#define WM_SIZE 5
#define WM_KEYDOWN 256// 0x0100
#define WM_KEYUP257// 0x0101
#define WM_MOUSEMOVE512// 0x0200
#define WM_LBUTTONDOWN 513// 0x0201
#define WM_LBUTTONUP514// 0x0202
#define WM_LBUTTONDBLCLK515// 0x0203
#define WM_RBUTTONDOWN 516// 0x0204
#define WM_RBUTTONUP517// 0x0205
static gint cb_event( GtkWidget *widget, GdkEvent * event, gchar* data )
{
gpointer gObject = g_object_get_data( (GObject*) widget, obj );
LONG lRes;
if( !pSym_onEvent )
pSym_onEvent = hb_dynsymFindName( ONEVENT );
//if( !gObject )
// gObject = g_object_get_data( (GObject*) (widget-parent-parent),
obj );
if( pSym_onEvent gObject )
{
LONG p1, p2, p3;
if( event-type == GDK_KEY_PRESS || event-type == GDK_KEY_RELEASE )
{
p1 = (event-type==GDK_KEY_PRESS)? WM_KEYDOWN : WM_KEYUP;
p2 = ((GdkEventKey*)event)-keyval;
p3 = ( ( ((GdkEventKey*)event)-state GDK_SHIFT_MASK )? 1 : 0 ) |
( ( ((GdkEventKey*)event)-state GDK_CONTROL_MASK )? 2 : 0 ) |
( ( ((GdkEventKey*)event)-state GDK_MOD1_MASK )? 4 : 0 );
}
else if( event-type == GDK_SCROLL )
{
p1 = WM_KEYDOWN;
p2 = ( ( (GdkEventScroll*)event )-direction == GDK_SCROLL_DOWN
)?
0xFF54 : 0xFF52;
p3 = 0;
}
else if( event-type == GDK_BUTTON_PRESS ||
event-type == GDK_2BUTTON_PRESS ||
event-type == GDK_BUTTON_RELEASE )
{
p1 = (event-type==GDK_BUTTON_PRESS)? WM_LBUTTONDOWN :
( (event-type==GDK_BUTTON_RELEASE)? WM_LBUTTONUP :
WM_LBUTTONDBLCLK );
p2 = 0;
p3 = ( ((ULONG)(((GdkEventButton*)event)-x)) 0x ) | ( (
((ULONG)(((GdkEventButton*)event)-y)) 16 ) 0x );
}
else if( event-type == GDK_MOTION_NOTIFY )
{
p1 = WM_MOUSEMOVE;
p2 = ( ((GdkEventMotion*)event)-state GDK_BUTTON1_MASK )? 1:0;
p3 = ( ((ULONG)(((GdkEventMotion*)event)-x)) 0x ) | ( (
((ULONG)(((GdkEventMotion*)event)-y)) 16 ) 0x );
}
else if( event-type == GDK_CONFIGURE )
{
p2 = 0;
if( widget-allocation.width !=
((GdkEventConfigure*)event)-width
||
widget-allocation.height!=
((GdkEventConfigure*)event)-height )
{
return 0;
}
else
{
p1 = WM_MOVE;
p3 = ( ((GdkEventConfigure*)event)-x 0x ) |
( ( ((GdkEventConfigure*)event)-y 16 ) 0x
);
}
}
else if( event-type == GDK_ENTER_NOTIFY || event-type ==
GDK_LEAVE_NOTIFY )
{
p1 = WM_MOUSEMOVE;
p2 = ( ((GdkEventCrossing*)event)-state GDK_BUTTON1_MASK )?
1:0
|
( event-type == GDK_ENTER_NOTIFY )? 0x10:0;
p3 = ( ((ULONG)(((GdkEventCrossing*)event)-x)) 0x ) | ( (
((ULONG)(((GdkEventMotion*)event)-y)) 16 ) 0x );
}
else
sscanf( (char*)data,%ld %ld %ld,p1,p2,p3 );
}
return 0;
}
any ideia?
Regards
Luiz
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
right,you should modify your codes again by virtue of to be in different
level(GTK and GDK).
if you were to focus on any widgets to get a piece of informations,then your
ways to be wrong!
--
View this message in context:
http://www.nabble.com/gtk_entry_new-and-accented-chars-tp14884653p19118756.html
Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Is there a way to invert gtk_ui_manager_get_path()
The function gtk_ui_manager_get_path() gets the xml path to a widget in your menu hierarchy. Is there a way, given a widget to find this path? Note this is not the path gotten from gtk_widget_path() which is the container hierarchy. I want the menu hierarchy (so as to be able to insert menu items there in some future invocation of the program). Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtkfilechooser question
Hi,
i'm facing a problem in the use of the gtk_file_chooser_dialog.
I'm developing a frontend for an antivirus scanner
and i need to pass to the scanner the path of the file OR folder
to scan. At the moment due to the nature of the
GtkFileChooserAction
typedef enum
{
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_FILE_CHOOSER_ACTION_SAVE,
GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER,
GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER
} GtkFileChooserAction;
I solved the problem by adding two buttons to the gui
one to select a file and one to select a folder.
This obviously is a suboptimal solution.
In the past i used a gtk_file_selection widget
for that function but i abandoned it as now it is deprecated.
After googling aroud a lot I tried various hacks to the gtk_file_chooser_dialog
by connecting to different signals and trying
to change the GtkFileChooserAction on the fly
with no result.
What I'm missing is a:
GTK_FILE_CHOOSER_ACTION_SELECT_FILE_FOLDER
action but i doubt the gtk people will implement
it for me :-).
I also started looking at the gtk_file_chooser
source to see if it is possible to implement
a private version of the widget for my app
but this looks like a rather difficult task.
Any hints are welcome as i'm at a dead end now
Thanks in advance and best regards,
Tito
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtkfilechooser question
Hi: GTK_FILE_CHOOSER_ACTION_SELECT_FILE_FOLDER action but i doubt the gtk people will implement it for me :-). I don`t see any reason to implement that in gtk. I believe you have design your own widget Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtkfilechooser question
On Saturday 23 August 2008 15:26:55 Martin (OpenGeoMap) wrote: Hi: GTK_FILE_CHOOSER_ACTION_SELECT_FILE_FOLDER action but i doubt the gtk people will implement it for me :-). I don`t see any reason to implement that in gtk. I believe you have design your own widget Regards. Hi, In my opinion there would be some reasons to implement it as this is a feature that could be useful in many cases. The fact that this feature is missing is a needless limitation to a tool that already has the capabilities to do that built in. There are examples for the need of this feature also in other OSes: the gui of Nero essentials pops up, after clicking on add, a standard win file chooser dialog that allows to add files and/or folders. The KDE open files dialog has it to... I think there could be more examples Last but not least the previous GtkFileSelection interface had this feature already and after deprecating it in my opinion it should be natural to offer in the replacement interface at least the same features as in the previous. Thanks for your response and best regards, Tito ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Lacking of a ref-counted string.
On Wed, 20 Aug 2008 21:07:39 -0400 Havoc Pennington wrote: If we think of GLib features as either for C, or for language bindings in general, or for vala, this particular feature seems like it would be *only* for vala - refcounted strings would be pretty strange in plain C, and just overhead for other language bindings that already have native string types they have to convert gchar* to. I personally have quite often wanted refcounted GStrings in normal programs that I've written; i.e. entirely unrelated to VALA. This issue comes up repeatedly, and each time the response is to ask for proof that it would make things better. How about the opposite, where's the proof that it would make things worse? Exactly how much slower would GTK get if it had to ref-count instead of copy strings everywhere, and how much more memory would it consume if it had to share a pointer instead of duplicating every string that gets passed in or out of a widget. How less stable will GTK be with proper string lifetime management built-in. How much more complicated is it for bindings (most of which use ref-counted strings themselves) to wrap a reference to a string instead of wrapping a whole new copy of the string. Strings can be significant, too, especially if you start writing them in some of the other multi-byte scripts supported by UTF-8, and quite frequently GTK will copy a string simply so that the programmer doesn't have to concern themselves with managing its lifetime until GTK is finished with it. Then when you ask for it back, sometimes you'll get a copy which you have to free when you're done with. And if in the meantime you give it to another widget, or even even back to a different property of the same widget, yet another copy gets made. And then there's g_strdup_printf() which is about the only decently safe way to use the printf() family of functions. And there you end up creating a string, handing it off to a GTK widget which immediately makes its own copy, and then you turn right around and g_free() it again. The alternative is to pre-calculate and pre-allocate memory for it, but that opens you up to the possibility of small off-by-1 errors, is generally fiddly and error-prone, is generally what g_strdup_printf() is supposed to make better. And still ends up being copied. A few times I've taken the source code to a widget, re-worked it to use ref-counted strings, and it certainly seemed an improvement to me. I could create a string, pass it into several properties of the widget, bring it back again, all without making a copy until I wanted to change it. The ref-counted strings are only needed where the value of a string is going to be retained, so a function that throws away the value and only keeps some computed result from it, doesn't need to bother with ref-counted strings at all, but that doesn't mean you can't pass in the raw C string from a ref-counted string. And I'm pretty sure addition and subtraction of a reference is a lot cleaner than returning a string just to have it g_free()'d by the caller. I can't very well do that with every widget I use, however, which is why I've been thinking of switching to using C++ The last argument I often hear against ref-counted strings, is thread-safety. What does that have to do with GTK, where you do all your GUI work from a single thread and use other threads as workers only. And just how is it any different to any other non-trivial GLib structure? If you want it to be thread-safe, you need to do some extra work to make it so. And of course you would use copy-on-write for any shared string, which makes it safe to pass around pretty much however you wish without having to worry. Simply duplicate and unref before you change it in any way, it still seems a great deal better than having to duplicate the string several times whether you change it or not. Maybe the GTK guru's don't need ref-counting and other tricks to be able to manipulate and pass around strings safely and efficiently, but the rest of us mere mortals could sure do with it. Personally I'd be happy with a GString that has type, ref-count, length, and gchar* members, where type refers to a structure containing the standard set of string operations, including conversion into and from GTK's native UTF-8. Having a different string type for I/O (including file names) compared to strings passed around GTK, protects us from encoding issues by allowing GTK widgets to safely assume their strings are correct simply by feeding them through a g_string_to_native() function (could even be done as a #define for efficiency) that will duplicate and convert if needed, or pass it through unchanged otherwise. But even just ref-counting alone would help, and even if it hurts efficiency a little, I fully believe it would be worth it. Fredderic ___ gtk-devel-list mailing list
Re: Lacking of a ref-counted string.
Hi, On Sat, Aug 23, 2008 at 8:29 AM, Freddie Unpenstein [EMAIL PROTECTED] wrote: This issue comes up repeatedly, and each time the response is to ask for proof that it would make things better. How about the opposite, where's the proof that it would make things worse? In software, everything starts with proof it makes things worse, because changing code definitely takes time and introduces bugs ... I mean that in all seriousness. This is especially true for API changes that ripple through hundreds or even thousands of third-party apps, which is what most GLib changes are. So if you do a pros and cons list on any GLib change, there is a big con, right up front, 100% known. I think that leads to an appropriate conservatism. For code that's in an app and not used by anyone else, you wouldn't want to see the same conservatism. Anyway... on ref-counted strings, I don't really remember this thread happening before (archive link?) so I'm not sure it comes up repeatedly. I'm not sure anyone on this thread has seriously proposed changing the whole stack of GTK APIs to use refcounted strings - certainly nobody has really written up what that would mean in detail, and tried to analyze pros and cons. If you're proposing this, I would say step back and explain what the actual proposal is, before addressing the objections ;-) Exactly how much slower would GTK get if it had to ref-count instead of copy strings everywhere If you're talking about converting existing APIs to refcounted strings, that's a very different proposal from just adding some kind of refcounted string feature. It would break thousands of apps, or else duplicate hundreds of API entry points ... How much more complicated is it for bindings (most of which use ref-counted strings themselves) to wrap a reference to a string instead of wrapping a whole new copy of the string. This one I can answer: most bindings would have to copy the strings into a native string type just as they do now. A few, maybe Vala and C++, could conceivably avoid the copy. So refcounted strings would not matter much for bindings in general but might help the C-like bindings. The last argument I often hear against ref-counted strings, is thread-safety. I thought people were using that as an argument _for_ refcounted strings. (Though I agree with your sentiment that GLib's approach to threads is not to make each individual data structure transparently thread safe.) But even just ref-counting alone would help, and even if it hurts efficiency a little, I fully believe it would be worth it. While I don't know what you're proposing in detail, I can't imagine efficiency is the issue. Huge API changes would be a much, much more significant factor. The other potentially obvious factor is programming convenience; refcounted strings in the GTK APIs would make some things easier, but other things (such as passing in a string literal) harder. Illustrating a particular proposal by porting some sample apps might demo these tradeoffs. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
