GTK treeview very slow?
Hi, I am running GTK treeview in a slow machine, say, with a 200MHz CPU, I am using a treeview with about 20 nodes as total. When I scroll the treeview scroll bar, the image get to freeze for a while... I then try with a simpler table with 1 column, the speed is quite fast, I can aware the freeze when scrolling. I want to confirm is my conclution is right? The treeview is significantly slower then other container? Thanks. Bin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gcolorsel-2.0 released
I just uploaded a tarball of gcolorsel-2.0.1, the enhanced gtk-2.x color selector, to http://primate.net/~itz/gcolorsel/ Major changes since the last public version (1.9.1): It is now possible to add the current color from the rainbow widget to the list widget; It is now possible to save the colors from the list widget to the original rgb.txt file, or to a different file; The program no longer hogs CPU time when you aren't dragging in the rainbow widget. Minor change: Use the modern gnome-like file selection dialogs from gtk 2.8. -- This line is completely ham. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Toggle and the Inconsistent Property
What is the inconsistent property to a toggle? I want to be able to flag rows in a treeview for possible deletion so they can be reviewed before flagging them for deletion. So the check box needs to have three states, kind of like the minesweeper game, checked, unchecked, and an inbetween state. Does anyone know how to do this? Thanks in advance, --dhk ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Toggle and the Inconsistent Property
On Sun, Sep 02, 2007 at 01:07:48PM -0400, dhk wrote: What is the inconsistent property to a toggle? I want to be able to flag rows in a treeview for possible deletion so they can be reviewed before flagging them for deletion. So the check box needs to have three states, kind of like the minesweeper game, checked, unchecked, and an inbetween state. Does anyone know how to do this? The inconsistent property is to display the toggle as in-between, or rather neither-yes-nor-no, state. However, what you describe does not really look like an in-between state. You have two states: - not marked for deletion - marked for deletion where the second has two sub-states. I suggest to think about a different presentation than abusing inconsistent (adding a small mark to one of the substates for instance), especially since the rendering of the states is theme dependent. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_widget_show() not showing window
Paul, I am not sure if you got an answer, so here is my expectation - am I am no expert. GTK _show/_hide api have an impact on the expose or painting function of gtk widgets. This effect is a consolidation of area needing repaint as a result of many factors. Thus a _show_all. _hide, and _show should be netted to the effect of a single gtk_widget_show(); unless there is an opportunity to process the gtk_main() loop in between calls; and I didn't see that. Is this your experience? James, On Tue, 2007-08-28 at 06:58 +, G. Paul Ziemba wrote: On Mon, 2007-08-27 at 19:00 +, G. Paul Ziemba wrote: gtk_widget_show_all(window); gtk_widget_hide(window); gtk_widget_show(window); gtk_main(); [EMAIL PROTECTED] (James Scott Jr) writes: Try this instead. The gtk_widget_show_all() then gtk_widget_hide() then gtk_widget_show() is the cause of your problem; unless you were thinking the window should blink once before appearing. gtk_widget_show_all(window); gtk_main(); Thank you for your suggestion - I must apologize because I should have mentioned (but forgot) in my original post that I am actually trying/helping to debug a problem in a larger piece of software (http://bugzilla.gnome.org/show_bug.cgi?id=467776). This test program is a minimal set of code that demonstrates the problem. My real question is, should the show_all/hide/show sequence work? thanks, ~!paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK Scrolls
Welcome, some time ago you send me the solution to remove a space between frame and scroll (like on this image: http://gnome-look.org/content/show.php?content=48820vote=goodtan=40330149 ) But I've lost that mail and don't remember source needed to be add to gtkrc :/ Can you send me it once again? I would be grateful. Regards pk ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK Scrolls
Am Donnerstag, den 30.08.2007, 11:30 +0200 schrieb bardzo_szorstki: Welcome, some time ago you send me the solution to remove a space between frame and scroll (like on this image: http://gnome-look.org/content/show.php?content=48820vote=goodtan=40330149 ) But I've lost that mail and don't remember source needed to be add to gtkrc :/ You want to play with the scrollbar-spacing style property. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On 9/1/07, Benjamin Berg [EMAIL PROTECTED] wrote:
On Fri, 2007-31-08 at 13:26 +0200, Lieven van der Heide wrote:
As for the general rendering of widgets, I think the current way of
letting the widget itself do the drawing, using a bunch of primitives
(ie. boxes, frames, etc.), and then letting the theme engines theme
just those primitives, instead of the whole widget, has shown to not
really work. What most theme engines seem to be doing now, is kind of
reverse engeneer those draw calls, and then render the theming in
their own way, which often is quite different from what the widget
actually thought is was drawing.
Most of the time these are special cases as for example making certain
corners rounded, but true.
I think it would be better if each widget just has it's own, specific
rendering class, which has a single function that should render the
complete widget at once. (this way, you kind of get a model/view
seperation inside controls). Themes can then override this rendering
class, and have complete freedom inside the render function of that
rendering class.
This sounds a lot like how QT works (I have not had a very deep look
though). However I don't think that any system should require build time
linking. As desktop environments (GNOME, maemo) and/or applications will
need custom widgets.
I don't really get what you mean with build time linking.
Custom widgets are perfectly possible with this approach. Even more so
than with the current approach. The thing is that the rendering
classes can query any other renderer of other widgets, to which they
forward their rendering. If you for example make a widget that's much
like a treeview, you should still make a specific renderer for that
widget, but make a default implementation that just forwards
everything to the treeview renderer. If a theme does not implement
this new widgets renderer, but it does implement the treeview
renderer, then the theming will still look good on both the treeview,
and on this new widget. If a theme engine decides that it does want to
have separate theming, it can implement the renderer of that new
widget, and render it in a different way completely.
This is a general problem that I have not brought up earlier. But I
wonder how to handle one widget that may have two different modes. An
example that is annoying me right now is the radiobutton. It can not
only be a drawn as normal radio button with an indicator, but also as a
button without an indicator (in eg. GtkRadioToolButton).
In the two different cases you may not only want to have some different
style for the radiobutton, but also for the widgets (label) inside. I
think that we either need to remove any case like this, have the
possibility to style widgets (and their children) based on properties or
need a second independent representation of the UI for theming.
Hm, I don't see a way right now to handle the connected buttons in a
button box with this approach nicely.
http://futurepast.free.fr/buttonbox.png
I think that's pretty much orthogonal to it. It will not solve it, but
it won't prohibit us from using something like that css system for it.
The thing that that css system could do, is to just select the
appropriate renderer, using the appropriate settings, depending on the
widget that's being rendered, and the surroundings of that widget.
Note that a single theme engine can have multiple implementations of
the same renderer class (ie. it can have two button renderers). The
css system can then pick a different renderer if the button is for
example neighboring another button.
Each renderer should also have a default implementation, which renders
the widget in a default way, using lower level rendering classes,
which render things like edges and boxes. If a theme engine doesn't
implement a specific widget's rendering class, but it did implement
the lower level ones, then it will still be rendered using something
that fits your theme (basically in the same way it's supposed to work
now).
It should also be possible for a renderer to use the renderer of
another (more basic) widget ,for example, a treeview could use the
button renderer as the default renderer for it's column headers.
pseudo code for the default renderer of a checkbox:
class CheckBoxRenderer
{
struct Params_s
{
int state;
string label;
}
virtual void render(GdkDrawable target,Params_s params)
{
// default implementation that uses the generic renderer
GenericRenderer generic_renderer = get_renderer(GENERIC_RENDERER);
generic_renderer.render_box(target,Rect(0,0,16,16));
if(params.state)
{
generic_renderer.draw_check(target,Rect(0,0,16,16));
}
generic_renderer.draw_text(target,Point(24,0),params.label);
}
}
In this example, overriding the generic renderer class will let you do
theming in the way it's done right now, overriding
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
On Sun, 2007-08-26 at 23:36 +0200, Olav Vitters wrote: Some documentation had different names and are correctly redirected. The rest uses a generic redirect. As soon as Frederic adds more documentation to libgo, I'll redirect the overview page as well (http://developer.gnome.org/doc/API/). What extra documentation is needed, by the way? Everything on the page: Some copy/pasting from a chatlog: | http://www.gnome.org/~mathieu/libart/libart.html -- copyright 2001, wtf? is a link now | libxml + libxslt point to elsewhere, not sure if have since been added as links This is on library.gnome.org now. | gstreamer So is this. as well also a link | do we have libgda? no idea | and of course gtkmm on libgo These are both there are links to the external site. (libgda is listed as gnome-db). So could you now please redirect http://developer.gnome.org/doc/API/ ? I'd then like to remove this directory from svn: http://svn.gnome.org/viewcvs/web-devel-2/trunk/content/doc/API/ -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
On Sun, Sep 02, 2007 at 06:13:20PM +0200, Murray Cumming wrote: So could you now please redirect http://developer.gnome.org/doc/API/ done. I'd then like to remove this directory from svn: http://svn.gnome.org/viewcvs/web-devel-2/trunk/content/doc/API/ It won't be removed from the server, but that is probably ok. -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
XGetWindowAttributes: 1x1 pixel for GTK apps?
Friends
I'm trying to get the dimensions (width and height) of current 'in focus'
window using XGetWindowAttributes.
It works fine with KDE or Xlib based applications, but fails with
all GTK based applications (window_attr.width and window_attr.height
reports just '1'). The same behavior happens in Ubuntu 6.06, 6.10, 7.04
when running Metacity as window manager (but not with Compiz or Beryl).
Following bellow a test app that demonstrates what I'm saying:
/***/
#include X11/Xlib.h
#include stdio.h
int main(void)
{
Display *display;
int res = -1, tmp, revert_to;
Window window;
XWindowAttributes window_attr;
display = XOpenDisplay(NULL);
if (!res)
return -1;
while (1) {
printf(will grab a window in 3s...\n);
sleep(3);
tmp = XGetInputFocus(display, window, revert_to);
if ((tmp == BadValue) || (tmp == BadWindow))
return -1;
tmp = XGetWindowAttributes(display, window, window_attr);
if ((tmp == BadDrawable) || (tmp == BadWindow))
return -1 ;
printf(width = %d\theigth = %d\n, window_attr.width,
window_attr.height);
}
return 0;
}
/***/
I already searched the internet for any information concerning
this, with no success. The gtk-app-devel-list doesn't return anything
(as also gtk-devel-list).
The only reference in bugzilla to XGetWindowAttributes is:
GDK cannot give input focus to an override_redirect window
http://bugzilla.gnome.org/show_bug.cgi?id=143349
Maybe I'm forgetting something related to Xlib, do you guys have
any idea of what is wrong here? Any of you know a way to known the
window dimensions of GTK apps *using xlib*?
Best regards
Adenilson
-
Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on,
when. ___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
