79 items | 6 visits
D C's List: Gtkmm
-
Apr 11, 12
bool Clock::on_timeout()
{
// force our program to redraw the entire clock.
Glib::RefPtr<Gdk::Window> win = get_window();
if (win)
{
Gdk::Rectangle r(0, 0, get_allocation().get_width(),
get_allocation().get_height());
win->invalidate_rect(r, false);
}
return true;
}-
bool Clock::on_timeout() { // force our program to redraw the entire clock. Glib::RefPtr<Gdk::Window> win = get_window(); if (win) { Gdk::Rectangle r(0, 0, get_allocation().get_width(), get_allocation().get_height()); win->invalidate_rect(r, false); } return true; }
-
-
Apr 11, 12
"bool Clock::on_timeout() { // force our program to redraw the entire clock. Glib::RefPtr<Gdk::Window> win = get_window(); if (win) { Gdk::Rectangle r(0, 0, get_allocation().get_width(), get_allocation().get_height()); win->invalidate_rect(r, false); } return true; }"
-
bool Clock::on_timeout() { // force our program to redraw the entire clock. Glib::RefPtr<Gdk::Window> win = get_window(); if (win) { Gdk::Rectangle r(0, 0, get_allocation().get_width(), get_allocation().get_height()); win->invalidate_rect(r, false); } return true; }
-
-
Apr 11, 12
struct GdkEventButton
struct GdkEventButton {
GdkEventType type;
GdkWindow *window;
gint8 send_event;
guint32 time;
gdouble x;
gdouble y;
gdouble *axes;
guint state;
guint button;
GdkDevice *device;
gdouble x_root, y_root;
};
-
struct GdkEventButton
struct GdkEventButton { GdkEventType type; GdkWindow *window; gint8 send_event; guint32 time; gdouble x; gdouble y; gdouble *axes; guint state; guint button; GdkDevice *device; gdouble x_root, y_root; };
-
-
-
Glib::RefPtr< Window > get_pointer (int& x, int& y, ModifierType& mask) Obtains the current pointer position and modifier state. -
Glib::RefPtr< Window > get_device_position (const Glib::RefPtr< const Device >& device, int& x, int& y, ModifierType& mask) const Obtains the current device position and modifier state.
-
-
-
-
Feb 26, 12
* amigadave has quit (leaving)
* JanC has quit (Read error: 145 (Connection timed out))
dbugger_: millions desrt: I think I found a bug then.... desrt: I'm even unable to do a printscreen to show you...so I'm taking a picture of my screen....just a sec... bad performance after how many items? desrt: about 1800 ya... that should not be a problem although it won't be particularly usable either desrt: oh...so it's DEFENITELY a serious bug since you have to scroll quite far to select item #1800 desrt: I know...I'm changing my design due to that...but I'd like to contribute, showing this bug * timebomb has quit (Remote closed the connection)
* emmanuel (~emmanuel@host155.201-253-134.telecom.net.ar) has joined #gtk+
* audifahrer_ (~andreas@p5B281D37.dip.t-dialin.net) has joined #gtk+
dbugger_: i'm trying to reproduce it desrt: ok * gusnan has quit (Lämnar)
desrt: by the way, I'm on Fedora16 with Gnome3 holy crap you weren't kidding desrt: oh u see! even at 1000 items the performance is hilariously bad desrt: I thought this was PRETTY BAD i'm going to attempt to take some measurements to determine what kind of broken we're dealing with here desrt: but did u had the visual problem? it just takes a really long time to show, for me * JanC (~janc@ip-213-49-118-197.dsl.scarlet.be) has joined #gtk+
so appending an item appears to be linear with a rather large constant factor (>1 µs on my rather beefy laptop) which is already worrying... desrt: for me, it takes long time to (the first time I expand it)... the following times, it show a "print screen" on my screen instead of the items list it always shows the correct thing for me it just takes a really really long time to do so to be sure: it never makes sense to put 2000 items in a combobox but the performance being this bad... * paulk (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) has joined #gtk+
dbugger_: please file a bug, in any case desrt: I just need to show u what I see.... just a sec http://fpaste.org/Wjfw/ is a pretty small program to demo the issue * audifahrer__ has quit (Ping timeout: 600 seconds)
* elima has quit (Remote closed the connection)
dbugger_: it's a bit surprising... the underlying data model in the combobox is the GtkTreeModel which has quite some advanced algorithms in it to make sure that it scales up to very large number of items gracefully desrt: that's pretty strange to me to... :S i suspect the combobox is making particularly unintelligent usage of it and since nobody ever tries to put more than a few items in one, nobody noticed until now mclasen: how long until it's polite to start bugging you about the minimized patch? desrt: yeah, that's why I trying to get some attention to this... desrt: already filed, #633178 desrt: take a look http://i43.tinypic.com/145ok7.png (sorry about the quality) dbugger_: i'd blame that on being some weird quirk with your graphics card before the window gets drawn (which is quite a long time since it takes so long) the contents are undefined and probably somehow a copy of your video memory is getting in there desrt: really? If I remember correctly, it worked well with gtk2 desrt: but that's ok... I hope I can get around this * timebomb (~timebomb@ip-109-40-82-172.web.vodafone.de) has joined #gtk+
dbugger_: i think the problem is strictly limited to the bad performance there was probably a regression somewhere along the way between 2 and 3 desrt: do u think I should report a bug (about the visual problem) ? no * wyuka has quit (Remote closed the connection)
i'm sure that's entirely an effect of the performance issue * nekohayo (~jeff@206-248-171-113.dsl.teksavvy.com) has joined #gtk+
desrt: I think I agree with u, cause on small comboboxes, it appears ok desrt: So, solving one problem, should solve the other? yes and apparently there is already a bug open about the first problem did you see it? https://bugzilla.gnome.org/show_bug.cgi?id=633178 * wyuka (~tirtha@111.93.171.226) has joined #gtk+
desrt: Yeah I saw that, was adding myself to the CC list....but it was reported in 2010?! if you wanted to work on fixing it, it would be appreciated but i think it's probably rather difficult to fix based on the fact that lots of very clever people seem to know it exists and it is not yet solved desrt: Yeah, it should be!... i'd dig in, but i already have a project for today that i should be getting started on :) desrt: I really wish I could help, but I'm still getting used to gtkmm3.0, and using it to develop a LARGE app to my boss... understood well i guess for now, you should avoid putting so much data into a combobox desrt: Think I'll contribute with $ and meanwhile know that it's a known issue desrt: That's what I'll do... think I'll use an Entry, with an EntryCompletion dbugger_: sounds like a good approach. reminds me of the project i'm working on now :p desrt: ;) * Notify: desrt is online (irc.gnome.org).
desrt: well, thank you very much for helping me! I really appreciated! sorry i couldn't give a real solution * zelvosaur has quit (Ping timeout: 600 seconds)
* desrt goes to do his 'real work' now :)
* Bitruder has quit (Read error: 104 (Connection reset by peer))
* jmd has quit (Remote closed the connection)
* Bitruder (~Bitruder@69-165-159-105.dsl.teksavvy.com) has joined #gtk+
desrt: that's ok... sorry for disturbing... gotta go ta -
Feb 25, 12
Dynamic allocation with manage() and add()
gtkmm provides the manage() function and add() methods to create and destroy widgets. Every widget except a top-level window must be added or packed into a container in order to be displayed. The manage() function marks a packed widget so that when the widget is added to a container, the container becomes responsible for deleting the widget.
MyWidget::MyWidget()
{
Gtk::Button* pButton = manage(new Gtk::Button("Test"));
add(*pButton); //add aButton to MyWidget
}
Now, when objects of type MyWidget are destroyed, the button will also be deleted. It is no longer necessary to delete pButton to free the button's memory; its deletion has been delegated to the MyWidget object.
gtkmm also provides the set_manage() method for all widgets. This can be used to generate the same result as manage(), but is more tedious:
foo.add( (w=new Gtk::Label("Hello"), w->set_manage(), &w) );
is the same as
foo.add( manage(new Gtk::Label("Hello")) );
Of course, a top level container will not be added to another container. The programmer is responsible for destroying the top level container using one of the traditional C++ techniques. For instance, your top-level Window might just be an instance in your main() function..-
Dynamic allocation with manage() and add()
gtkmm provides the manage() function and add() methods to create and destroy widgets. Every widget except a top-level window must be added or packed into a container in order to be displayed. The manage() function marks a packed widget so that when the widget is added to a container, the container becomes responsible for deleting the widget.
Now, when objects of type MyWidget are destroyed, the button will also be deleted. It is no longer necessary to delete pButton to free the button's memory; its deletion has been delegated to the MyWidget object.MyWidget::MyWidget() { Gtk::Button* pButton = manage(new Gtk::Button("Test")); add(*pButton); //add aButton to MyWidget }gtkmm also provides the set_manage() method for all widgets. This can be used to generate the same result as manage(), but is more tedious:
foo.add( (w=new Gtk::Label("Hello"), w->set_manage(), &w) );
is the same as
foo.add( manage(new Gtk::Label("Hello")) );
Of course, a top level container will not be added to another container. The programmer is responsible for destroying the top level container using one of the traditional C++ techniques. For instance, your top-level Window might just be an instance in your main() function..
-
-
Feb 25, 12
Note that we don't pass a pointer to on_button_clicked() directly to the signal's connect() method. Instead, we call sigc::ptr_fun(), and pass the result to connect().
sigc::ptr_fun() generates a sigc::slot. A slot is an object which looks and feels like a function, but is actually an object. These are also known as function objects, or functors. sigc::ptr_fun() generates a slot for a standalone function or static method. sigc::mem_fun() generates a slot for a member method of a particular instance.-
Note that we don't pass a pointer to on_button_clicked() directly to the signal's connect() method. Instead, we call sigc::ptr_fun(), and pass the result to connect().
sigc::ptr_fun() generates a sigc::slot. A slot is an object which looks and feels like a function, but is actually an object. These are also known as function objects, or functors. sigc::ptr_fun() generates a slot for a standalone function or static method. sigc::mem_fun() generates a slot for a member method of a particular instance.
-
-
-
The Actions/Keys:
Legend: all the funky keys in here (like right arrow, left arrow, tab, etc.) are represented by their entries in the gdk/gdkkeysyms.h file
-
-
-
Jan 21, 12
OOOOTIMO
http://www.optionexplicit.be/projects/gnome-windows/GTK 3/ -
-
- Glib::ustring and stream input/output
- The stream I/O operators, that is operator<<() and operator>>(), perform implicit charset conversion to/from the current locale. If that's not what you intented (e.g. when writing to a configuration file that should always be UTF-8 encoded) use ustring::raw() to override this behaviour.
- If you're using std::ostringstream to build strings for display in the user interface, you must convert the result back to UTF-8 as shown below:
std::ostringstream output; output.imbue(std::locale("")); // use the user's locale for this stream output << percentage << " % done"; label->set_text(Glib::locale_to_utf8(output.str()));
-
-
-
<!-- doxytag: member="Glib::locale_to_utf8" ref="ga4517b17f2aad4cd5c0e0640de212d928" args="(const std::string &opsys_string)" -->
std::string Glib::locale_from_utf8 ( const Glib::ustring& utf8_string ) Convert from UTF-8 to the current locale's encoding.
Convenience wrapper around Glib::convert().
- Parameters:
-
utf8_string The UTF-8 string to convert.
- Returns:
- The input string converted to the charset used by the operating system's current locale.
- Exceptions:
-
Glib::ConvertError
Glib::ustring Glib::locale_to_utf8 ( const std::string & opsys_string ) Convert from the current locale's encoding to UTF-8.
Convenience wrapper around Glib::convert().
- Parameters:
-
opsys_string The string to convert. Must be encoded in the charset used by the operating system's current locale.
- Returns:
- The input string converted to UTF-8 encoding.
- Exceptions:
-
Glib::ConvertError
-
List Comments
(0)
List Info