GNOME Bugzilla – Bug 332446
API additions
Last modified: 2006-06-01 09:09:20 UTC
Please describe the problem: 1) Glib::RefPtr::operator < (), for the ability to store RefPtr's in ordered STL containers (e.g. std::set) 2) Glib::RefPtr::get() - to retrieve T* 3) wrapper for g_strsplit function 4) Gdk::Rectangle lacks operator == and operator != 5) wrappers for gtk_window_set_accept_focus and gtk_window_set_focus_on_map 6) wrappers for GtkMenuShell and GtkMenuBar properties (new in GTK+ 2.8) Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
1) Sounds OK. A patch would be welcome. 2) See http://bugzilla.gnome.org/show_bug.cgi?id=101878. This will not be added until someone finds a case where it is needed. Otherwise, it would only be used where it should not be used, and that's not something that I want to encourage. 3) Patch welcome. Are you sure that this can't be done with the standard C++ library. You might ask on the mailing list if you are not sure. 4) Patch welcome. 5) Patch welcome. 6) Patch welcome. Please try to put completely different bugs in different bugzilla bug reports. For instance, g_strsplit has nothing to do with GMenuShell.
2) The function may be useful for RefPtr'ing managed widgets, but it is a very special case indeed. 3) g++ seems to have something similar but it is not Standard C++. Anyway g_strsplit has a nice feature to work with utf-8 strings. http://gcc.gnu.org/onlinedocs/libstdc++/21_strings/howto.html#3 Sorry, I cannot make patches now.
2) I don't understand. You need to give a definite example. I don't know of any case where you would want to put a managed widget into a RefPtr. When you manage a widget, you have surrendered its memory management, so there's no point in refing or unreffing it.
Surrendered to whom? The documentation for Managed Widgets says "you can let a widget's container control when the widget is destroyed". I understand "destroyed" here as: 1) destroyed by gtk_object_destroy and 2) freed by operator delete when refcounter drops to zero. This means that the managed widget's lifetime (partly) depends on normal GTK+ refcounting. gtkmm tries to hide this and I think it is right, but... The need to use RefPtr's with widgets arises in a situation when an application has to manage Gtk::Object's and Glib::Object's in some unified way. This is tricky, because a widget may be destroyed and not freed if refcounter still > 0; and Gtk::Window's must be finalized differently. Ok, I revoke request for RefPtr::get() function. Please do not close this entry, may be someone (me in some future) will provide patches: new bugzilla entries should be opened for each case except 2)
> I understand "destroyed" here as: 1) destroyed by gtk_object_destroy and 2) > freed by operator delete when refcounter drops to zero. This is neither very meaningful or true. Managed child widgets are simply destroyed when their parent widgets are destroyed. No more, no less. And there is no additional "gtk destroyed" concept. When I say destroyed I am talking about normal C++ memory management. > The need to use RefPtr's with widgets arises in a situation when an > application has to manage Gtk::Object's and Glib::Object's in some unified way. You can put both Glib::RefPtr<SomeGlibObject> and Gtk::SomeWidget in a generic sharedptr<> in C++. Reference-counting of widgets will not really work in GTK+ in C either, because parent widgets don't care - they just destroy child widgets regardless.
It would be nice to have patches for some of these things, in appropriate bugzilla bugs.
Hello, I am okay to add patches for 1) and 3). I'll post them here asap. Dodji.
>This is neither very meaningful or true. Managed child widgets are simply >destroyed when their parent widgets are destroyed. No more, no less. And there >is no additional "gtk destroyed" concept. When I say destroyed I am talking >about normal C++ memory management. GTK+ widget can be in a "destroyed" state and occupy memory until there are no references to it. See refcounting.txt in GTK+ source tarball under docs directory. >You can put both Glib::RefPtr<SomeGlibObject> and Gtk::SomeWidget in a generic >sharedptr<> in C++. This is not very useful because such sharedptr's will be incompatible: one that holds Glib::RefPtr<> cannot take Gtk::Widget. >Reference-counting of widgets will not really work in GTK+ >in C either, because parent widgets don't care - they just destroy child >widgets regardless. See refcounting.txt
> GTK+ widget can be in a "destroyed" state and occupy memory until there are no > references to it. See refcounting.txt in GTK+ source tarball under docs > directory. I believe this is a very short intermediate state. As soon as destruction happens we forget about widgets and try to never use them again. This state is of no use to application programmers. Likewise, there is no Gtk::Object::destroy() in gtkmm, because C++ has delete. > >You can put both Glib::RefPtr<SomeGlibObject> and Gtk::SomeWidget in a generic > >sharedptr<> in C++. > This is not very useful because such sharedptr's will be incompatible: one that > holds Glib::RefPtr<> cannot take Gtk::Widget. Obviously not and I don't know why you would want to do that.
>I believe this is a very short intermediate state. As soon as destruction >happens we forget about widgets and try to never use them again. This state is >of no use to application programmers. The main conclusion here is that this "corner" state is valid and not a bug. The state may last arbitrary time unless a widget is referenced by its container only. >Obviously not and I don't know why you would want to do that. As I said earlier, to have Glib::RefPtr<Glib::Object> that can hold any GTK+ object including Gtk::Widget. Actually this works perfectly now, the question was whether to add "T * Glib::RefPtr<T>::get()" function. The real-world examples that require such functionality usually are not ordinary GUI applications. One good example is a GUI serialization. It is convenient and reasonable for the implementation to use the same code path for storing and loading Glib::Object's, Gtk::Object's and Gtk::Window's.
> The main conclusion here is that this "corner" state is valid and not a bug. Again,, I disagree. Feel free to show me something specific and useful that you can't do with the current API. > As I said earlier, to have Glib::RefPtr<Glib::Object> that can hold any GTK+ object including Gtk::Widget. Actually this works perfectly now, No, that's a bad idea. It doesn't work. You'll end up with a pointer to an invalid/freed widget. When you try to use it your program will crash. There's no need to get lost in theory here. Simple examples would be more persuasive.
>Again,, I disagree. You disagree with the fact. Any honest reader of this entry who understands GTK+ memory management may confirm this. >Feel free to show me something specific and useful that you >can't do with the current API. "Feel free"? You probably have some wrong assumptions about my posts or Bugzilla. >No, that's a bad idea. This idea is usually called polymorphism; it is not bad at all. >It doesn't work. You'll end up with a pointer to an >invalid/freed widget. When you try to use it your program will crash. Wrong assumptions again: I didn't say that the destroyed but not yet freed object must be used somehow. >There's no need to get lost in theory here. Simple examples would be more >persuasive. The example with serialization is enough practical, simple and persuasive.
> The example with serialization is enough practical, simple and persuasive. Sorry. What example? I see no source code in this whole bug report.
>Sorry. What example? I see no source code in this whole bug report. "Feel free" to write source code yourself. I posted comment #8 in order to show that comment #5 is misleading. The reader now has enouth information to make a right conclusion.
The purpose of an example would be to show me what can't be done with the current API. I can't write an example to show myself something that I don't understand or believe. If I had enough information then I wouldn't be asking for you to make it clearer.
>The purpose of an example would be to show me what can't be done with the >current API. I can't write an example to show myself something that I don't >understand or believe. If I had enough information then I wouldn't be asking >for you to make it clearer. I revoked a request for RefPtr::get function in comment #4. I don't understand what source code you are asking. If you want to discuss GTK+/C++ serialization issues, that should be done elsewhere.
I really have no idea what you are talking about any more. In particular I have no idea what you mean by "serialization" here. I am asking for source code so you can say "Look, I would like to do this but there's no API for it here.". With great patience I am trying very hard to discover what you need. If there is something specific that you need, please do open a new bug and try to be clear about it.
>I really have no idea what you are talking about any more. In particular >I have no idea what you mean by "serialization" here. It's default meaning, as defined in Computer Science: http://en.wikipedia.org/wiki/Serialization >I am asking for source code so you can say >"Look, I would like to do this but there's no API for it here.". When did I tell you that I want to say this? You constantly make wrong assumptions about my posts. >With great patience I am trying very hard to discover what you need. If there >is something specific that you need, please do open a new bug and try to be >clear about it. I clearly described all six feature-requests in this bugzilla entry. (They may be easily discovered at the top of this page, with little patience.) Later I revoked request [2]. Yesterday I posted comment #8 (and I am not asking for [2] anymore), but instead of admitting your mistake (comment #5) you are trying to convince me that I owe you some source code. I bet people will have fun reading this entry.
Maxim, I am just trying to help you. I can not help you based on the current information, whether or not you think I should understand perfectly. I am trying to suggest how you can make me understand. Asking you for further information in order to find out how to do some work for you is hardly "trying to convince me that I owe you some source code". Why should I keep bothering?
This bug is closed because it's making me feel used and abused and I get to say when that stops. Patches for any of the non-controversial stuff would be welcome in their own bug reports.
>Maxim, I am just trying to help you. I can not help you based on the current >information, whether or not you think I should understand perfectly. I am >trying to suggest how you can make me understand. Murray, how many times I need to repeat that a request for [2] was revoked in comment #4? What is that "help" you keep talking about? It was *you* who started a dispute with your comment #5. I replied because your comment contains wrong information about GTK+ memory management, and *not* because I need something from you. >Asking you for further information in order to find out how to do some work for >you is hardly "trying to convince me that I owe you some source code". I am not your employer, so don't do work for me - do work for GTK+/C++ community.