drag and drop
I need to drag and drop from my app to the opsys desktop or folder. This is an email so it is part of a mailbox file. Or it could be some other part like an attachment of the email. does mailbox:// protocol automatically handle the drop in opsys? I find a lot of code using drag and drop but they are text messages or url's and not particular to this situation where the app may need to formulate the data and file name. -- Phil ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Drawingarea in a scrolled window
hi! I've put a drawing area into the scrolled window. My drawing are is bigger than the scrolled window and there're problems about the refresh. How can I fix that? Please help me!! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drawingarea in a scrolled window
I know this is not answering your question, but you can get the same effect of the drawing area by using my GtkImageViewer widget, without an image. See the tutorial at: http://giv.sourceforge.net/gtk-image-viewer/gtkimageviewer_tutorial.html for an example. Regards, Dov 2009/4/12 Paolo pra...@gmail.com hi! I've put a drawing area into the scrolled window. My drawing are is bigger than the scrolled window and there're problems about the refresh. How can I fix that? Please help me!! ___ 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:RadioMenuItem
Hi, Because they are in the same group,and if one is selected(or toggled), then before it send a toggled signal,the other one which becomes unselected will also send a toggled signal. So you can use if (gtk_toggle_button_get_active(button)) to check the state of button in your callback functions , and then do what you want to do. Wish You happy. Dong 2009-04-13，Paolo pra...@gmail.com ： How can I get the state of my radiomenuitem inside a callback function? This is the situation: I've a group of two radiomenuitems; each of them holds a callbacks function that listen the toggled signal. The signal fires for both radiomenuitems if I push singleradiomenuitem. Why? And how can I fix that? Thanks ___ 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: What gives us the macro GSEAL()?
Grzegorz Kuczyński a écrit :
Colomban Wendling pisze:
AFAIK, it is used to hide members of GTK+ and GDK structures that
will become opaques in future releases (3.0 or so); then it makes
easy to see if a source must be updated not to use direct access
of members. In practice, compilation of a source code accessing
directly struct members with GSEAL_ENABLE defined will fail
because member have another name (_g_sealed__name).
So the GSEAL() macro replaces old names.
Yes. It renames them (in a way you're not intended to know) to hide them.
Because in GTK+ 3 maybe create a new name or type for 'title'
property and still not erase old members? Old hide in:
window-_g_sealed__title
I good understand?
No, it is not exactly what I would mean, sorry if I was unclear.
AFAIK (I'm not a GTK+ hacker, I can be wrong) in GTK+ 3.0, structures
may become opaques, opaques meaning that you can't access to members
of those structs because the C compiler doesn't know about them
outside the C file, then not in the header.
In practice, you have in your header something like that in gtkfoo.h:
typedef struct _GtkFoo GtkFoo;
and in gtkfoo.c:
struct _GtkFoo { ... };
then in files including gtkfoo.h, only the structure itself is visible
and know, but none of its members.
The main interest I see in disallowing access to members is that it
allows to change the object's internals (by object I mean something
like a structure and functions to manipulate it) without breaking
anything outside the object's code itself; e.g. if it make sense to
completely rewrite the GtkWindow structure, the API wouldn't be broken
in any way (and I think it wouldn't broke ABI too, but not sure for
that) since the object's specification doesn't include low-level
implementation details such as structure's members.
This is a concept close to the privates members in some OO languages:
you CAN'T use them outside the object's implementation.
A common opaque object is the C's FILE object that is not defined to
be implemented in a way or another, only functions using this kind of
objects are defined; then any implementation of the FILE object will
work the same way with any source code using it, regardless of what is
needed behind to do the work.
Moreover, it gave more robust objects since the user can't corrupt
them by setting an unexpected value to an object's member (but if
programmers corrupts the libraries they use, they are just stupid,
nothing more).
Well, in simple words, people accessing directly GTK object's members
will have to rewrite their code to use accessors (like
gtk_window_get_title() for the window's title case).
I hope I was clear (and haven't done too much language mistakes, I'm
not English too ;)).
Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
Am Sat, 11 Apr 2009 13:55:36 -0400 schrieb Havoc Pennington havoc.penning...@gmail.com: Hi, On Sat, Apr 11, 2009 at 11:06 AM, Matthias Clasen matthias.cla...@gmail.com wrote: What David is saying (and I'm sure you understood) is that glib already comes with a type system, namely GType. Adding a completely separate one next to it in the same module is problematic, even if it is a well-loved one. I'm trying to think about this myself. Here are some thoughts. * glib serialization has been discussed in the past, e.g. http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00021.html * GVariant is basically a particular serialization format. It happens to use the same types as the dbus format. [...] Hiding the signature string format and using GType for that seems like it does not change anything semantically, it's just cosmetic in some sense. Using G_TYPE_FOO in the API is imho a lot more agreeable than any new string signature. Sure it's more to type, but at the same time it's more comprehensible. :) 2. try to use GLib types instead of having a custom value type, i.e. the dreaded GHashTable of GValue, or GArray that is a struct. This would seem to be both inconvenient, incomprehensible, and so bloated it may destroy the purpose of using mmap'd files. So some sort of serialized data value object like GVariant would appear to be needed? In short, if you have a dbus struct or dictionary, or mmap file struct or dictionary, what is the API to access that? This doesn't seem cosmetic to me. It's a fundamental question whether there's a serialized data value object and which types can go in it. I think this goes in the general direction of whether a particular GType can be serialzed and deserialized at all. For what I want, an object that for example represents an XML document, can very well be serialized. Of course that is entirely specific to the object type. Attempting to bring an object into a storable format is otherwise not a stupid idea imho. Maybe GType needs an interface so any type can implement what boils down to g_type_serialize, g_type_deserialize and g_type_can_serialize. If you think passing types to DBus that are not part of DBus will lead to problems, it might just be a matter of documenting that in Glib. * I would think of the type system of GVariant more like g_key_file_get_integer(), g_key_file_get_boolean(), g_key_file_get_integer_list() than it is like GType. The GVariant signature format is obviously far more complex than what GKeyFile supports; but *conceptually* it's equivalent to GKeyFile, right? It's pretty much an API for mmap'd files and for dbus IPC, just as keyfile is an API for .ini text files. You are asserting that something like a gint or guint is not something that can be saved to disk. Please take another look at the signature of g_key_file_get_integer. At the very least, you shouldn't compare GKeyFile with GVariant if you think one of them is broken by design, otherwise you are contradicting yourself :) That said, it is all too common, for better or worse, to work with numbers of unknown physical size, including storage to disk. It's fine with me to say it may not be a good idea, but I don't believe this is a DBus related problem at all. Granted, making it look like a GVariant specific issue is easier than trying to deprecate gint and guint. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What gives us the macro GSEAL()?
Very thanks Regards.
Ok I understand the idea, but...
how work it? for example:
---
struct _GtkWindow
{
GtkBin bin;
gchar *GSEAL (title);
---
void
gtk_window_set_title (GtkWindow *window,
const gchar *title)
{
char *new_title;
g_return_if_fail (GTK_IS_WINDOW (window));
new_title = g_strdup (title);
g_free (window-title);
window-title = new_title; // I don't know property title!!!
---
So, when define GSEAL_ENABLE code in gtkwindow.c must change in
window-_g_sealed__title = new_title; //??
Maybe I can read anywhere for idea macros GSEAL?
I don't want write stupidity in Wikibooks. Because I want write analize
for struct GtkWindow AND I myself want understand :)
---
Grzegorz Kuczyński
--
Wirtualne zyczenia wielkanocne? Sprawdz!
Kliknij http://link.interia.pl/f2118
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
Hi, On Sun, Apr 12, 2009 at 9:14 AM, Christian Dywan christ...@imendio.com wrote: You are asserting that something like a gint or guint is not something that can be saved to disk. I'm not saying that; I'm saying they can only be saved to disk by converting them to a fixed-size integer. int is a bad example because for all machines glib runs on, int is equal to int32. But let's look at long; long means different things on different machines. This makes it totally broken to save long to disk or push it over the network. It's OK to autoconvert long to int32 ... but there's no meaningful long type once we're serialized, imo. That said, it is all too common, for better or worse, to work with numbers of unknown physical size, including storage to disk. It's impossible to do this, imo. Once you save to disk the physical size is locked in Yes you can write a super-broken program that saves to disk at a different size depending on the cpu it's running on, but that super-broken program is still going to be picking either int32 or int64 when it goes to save the long. Basically, typedefs don't mean anything once you're serialized. A serialized format could support time_t, size_t, long, ssize_t, pid_t, etc. etc. (this goes on forever); or it could support int32, int64, uint32, uint64 and that's it. I would advocate the second; have the type system of a serialized format describe the actual binary data types, not every way those binary data types can be interpreted or mapped into language types. This is a pretty fundamental decision, I went into more in my other mail, with two slightly different angles on it or ways to frame it. a) union of all type systems (GType, python, JavaScript, Java, etc.) or rough intersection of primitive types they have in common b) round-trip full native (GType, python, JS, Java, etc.) type knowledge through the serialization, or preserve the binary storage format only For disk formats and ipc formats, I think intersection / binary format only is the right way to lean, rather than union/full-type-annotation-knowledge. Something like Python pickle or Java serialization round-trip the full native type knowledge, but they are completely specific to the particular native type system. Reading a python pickle file or Java serialization from another language is a headache at best. The upside to the pickle/Java-serialization approach is total convenience when working in that language; these formats are really good for quick hacks. If you add to something like the dbus format the ability to add custom type annotation, so you could say this int32 is really G_TYPE_LONG or this int64 is really time_t then what you're doing in effect is creating a dialect of the serialization format for each language runtime or framework, most likely basically sharing code among a collection of language/framework-specific python-pickle-like systems. For the two use-cases at hand here (dbus, mmap'd cache files), being extremely GType-specific seems bad, for the same reasons that Python pickle or Java serialization would be poor choices. There's nothing wrong with supporting autoconversion of native types to serializable types. So for example if you store G_TYPE_LONG or G_TYPE_INT, those could be automatically serialized as INT32. However, I don't think you should get those types back out when you read; reading the file back should give you INT32 only. And LONG should go to INT32 consistently, regardless of the CPU it's running on. The round-trip should not be supported, in short. The other thing one could do is build a GType-based pickle-like feature *on top* of a more interoperable binary format. What you'd do in this case is that you would store a GType name as a string, plus a GVariant value. You could then serialize/unserialize GTypes with full information preserved through the round-trip. That illustrates really well, perhaps, how there are two layers here. There's a binary format and a type system that describes the *format*; and then there's the type system of the language runtime or framework, which could be Python, GType, Java, or whatever. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
Hi, On Sun, Apr 12, 2009 at 9:14 AM, Christian Dywan christ...@imendio.com wrote: Using G_TYPE_FOO in the API is imho a lot more agreeable than any new string signature. Sure it's more to type, but at the same time it's more comprehensible. :) I don't disagree for C. One thing to note though, it isn't really more comprehensible in Python or JavaScript or something, where otherwise GType can pretty much be ignored. In fact in Python or JS you're probably more likely to be looking at some dbus or file format docs that use the serialized signatures in the docs, than you are to be looking at GType-based docs. Having to go JavaScript type - GType - serialized type is just an extra hoop. I think it might be helpful to call the GVariant signature something about binary format. What means GBinaryLayoutDescription but is shorter? ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
Hi, On Thu, Apr 9, 2009 at 11:38 AM, Dan Winship d...@gnome.org wrote: So, my feedback is, if the type system is explicitly just D-Bus and nothing else, shouldn't it be called GDBusType or something? (I'm not saying it's *bad* that it's D-Bus-specific, just that it should be more explicit about it.) Reading the gvariant and gbus source btw, this would be somewhat misleading at the moment; gvariant's type system is a dbus superset, and its serialization format is a proposed dbus v2 format that may or may not ever get used by dbus. (One of the main barriers being that nobody afaik is working on adding feature negotiation or protocol v2 support to libdbus yet, so there would not be a bus daemon or a least-common-denominator / plain-C / zero-dependencies library supporting the v2 protocol.) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What gives us the macro GSEAL()?
2009/4/12 Grzegorz Kuczyński gk180...@interia.pl:
Very thanks Regards.
Ok I understand the idea, but...
how work it? for example:
---
struct _GtkWindow
{
GtkBin bin;
gchar *GSEAL (title);
---
void
gtk_window_set_title (GtkWindow *window,
const gchar *title)
{
char *new_title;
g_return_if_fail (GTK_IS_WINDOW (window));
new_title = g_strdup (title);
g_free (window-title);
window-title = new_title; // I don't know property title!!!
---
So, when define GSEAL_ENABLE code in gtkwindow.c must change in
window-_g_sealed__title = new_title; //??
gtk_window_set_title().
Maybe I can read anywhere for idea macros GSEAL?
I don't want write stupidity in Wikibooks. Because I want write analize for
struct GtkWindow AND I myself want understand :)
---
Grzegorz Kuczyński
-A. Walton.
--
Wirtualne zyczenia wielkanocne? Sprawdz!
Kliknij http://link.interia.pl/f2118
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What gives us the macro GSEAL()?
2009/4/12 A. Walton awal...@ubuntu.com:
2009/4/12 Grzegorz Kuczyński gk180...@interia.pl:
Very thanks Regards.
Ok I understand the idea, but...
how work it? for example:
---
struct _GtkWindow
{
GtkBin bin;
gchar *GSEAL (title);
---
void
gtk_window_set_title (GtkWindow *window,
const gchar *title)
{
char *new_title;
g_return_if_fail (GTK_IS_WINDOW (window));
new_title = g_strdup (title);
g_free (window-title);
window-title = new_title; // I don't know property title!!!
---
So, when define GSEAL_ENABLE code in gtkwindow.c must change in
window-_g_sealed__title = new_title; //??
gtk_window_set_title().
Sorry about that, hit the wrong button (backspace is not return).
gtk_window_set_title() is inside of gtk+ and won't need to change. The
macro is to prevent external applications from doing window-title =
whatever; and instead applications should (and will be forced to use)
gtk_window_set_title().
-A. Walton
Maybe I can read anywhere for idea macros GSEAL?
I don't want write stupidity in Wikibooks. Because I want write analize for
struct GtkWindow AND I myself want understand :)
---
Grzegorz Kuczyński
-A. Walton.
--
Wirtualne zyczenia wielkanocne? Sprawdz!
Kliknij http://link.interia.pl/f2118
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
On Sun, 2009-04-12 at 14:55 -0400, Havoc Pennington wrote: Hi, On Sun, Apr 12, 2009 at 9:14 AM, Christian Dywan christ...@imendio.com wrote: You are asserting that something like a gint or guint is not something that can be saved to disk. I'm not saying that; I'm saying they can only be saved to disk by converting them to a fixed-size integer. int is a bad example because for all machines glib runs on, int is equal to int32. But let's look at long; long means different things on different machines. This makes it totally broken to save long to disk or push it over the network. It's OK to autoconvert long to int32 ... but there's no meaningful long type once we're serialized, imo. That said, it is all too common, for better or worse, to work with numbers of unknown physical size, including storage to disk. It's impossible to do this, imo. Once you save to disk the physical size is locked in Yes you can write a super-broken program that saves to disk at a different size depending on the cpu it's running on, but that super-broken program is still going to be picking either int32 or int64 when it goes to save the long. Basically, typedefs don't mean anything once you're serialized. A serialized format could support time_t, size_t, long, ssize_t, pid_t, etc. etc. (this goes on forever); or it could support int32, int64, uint32, uint64 and that's it. I would advocate the second; have the type system of a serialized format describe the actual binary data types, not every way those binary data types can be interpreted or mapped into language types. This is a pretty fundamental decision, I went into more in my other mail, with two slightly different angles on it or ways to frame it. a) union of all type systems (GType, python, JavaScript, Java, etc.) or rough intersection of primitive types they have in common b) round-trip full native (GType, python, JS, Java, etc.) type knowledge through the serialization, or preserve the binary storage format only For disk formats and ipc formats, I think intersection / binary format only is the right way to lean, rather than union/full-type-annotation-knowledge. What about a format like this (the numbers are somewhat arbitrary, they may need to be adjusted for performance in the particular use case): Blocks of Data: 1st bit tells if there is a label if 1st bit is 1: next byte gives us the length of the label, L = ceiling(log[2](length in bytes)) (which gives us up to up to 256 characters, so we can have quite large namespaces, but without wasting space) the next L bytes contain the label (in some chosen encoding, but that's a different discussion) the next bit tells if the label is continued, if it is the next byte is again the length (so we can have labels as long as we want... maybe this isn't necessary, but it's only one bit). rinse, repeat once the label is finished (or the first bit of the data section is 0), the next byte gives the length of the data, again, L = ceiling(log[2] (length of data in bytes)) the next L bytes are the data the next bit after the data is the continue bit Once the data is finished, we start the next block. Perhaps we would want to steal one bit from the length field for the continue bit. It cuts the possible size of our data/label in half, but keeps us lined up on bytes. Maybe there's something fundamentally wrong with this for this particular use case, but it would allow the application and library developers a lot of flexibility in how they want to store the data; whether they wanted to tie the data to types/names/tag it somehow. With this, structs without pointers could be pretty trivially serialized. Even the code to serialize/deserialize structs with pointers doesn't seem like it would be too bad... all the pointers could be stored separately and tagged as such, and simply point to the position in the file/datastream. Of course, we would have calculate the size of the pointers, but that would be a function of the size of the nonpointer data and the total number of pointers, which shouldn't be too hard to calculate. Like I said, maybe I'm way off in left field... I honestly don't really know what exactly the use cases for this are. But I figured I'd throw my 2 cents into the ring. -Larry la...@yrral.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
