Re: memory leak when destroying widgets
Hi, On Mon, Oct 27, 2008 at 4:22 PM, Jacques Le Normand <[EMAIL PROTECTED]>wrote: > >gtk_container_remove(GTK_CONTAINER(vbox),child); > Most likely I am wrong on this, but you solely do a container remove, and not a delete/free etc on something that was created with entry_new(). I'm fairly certain that removing from a container does not free the the object, and you are therefore leaking 400 pointers to entry boxes. dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: treeview path/iter to undisplayed model item
After further testing, I've concluded it is a strange interaction between the xmms2 client lib (my application is an xmms2 client) and the glib mainloop. I found a workaround in that instead of placing items in the store directly when xmms2 tells me to, I put it in a queue for an idle function to pick up later. That seems to solve it atm. dave On Mon, Sep 15, 2008 at 10:30 AM, Dave Foster <[EMAIL PROTECTED]> wrote: > Hi all - > > I have a situation in my application where I'd like to do something with an > iterator/treepath that I've just added to the model. Specifically, I need > to do things like get_cell_area and scroll_to_row in certain instances. It > seems I am unable to get valid results out of these functions until after > the tree view control has rendered them. Calling get_cell_area will give > the area of a DIFFERENT cell (ack!) and scroll_to_row will simply do > nothing. > > Is there a way to determine if an iter/treepath has been displayed or could > be displayed (not in the current scrolled area of the treeview)? I don't > know how else to solve my problem. Using a timeout works some of the time > but since I cannot accuratly determine if the treepath I have is going to > work with those functions it's more of a bandaid then a solution. > > As suggested on the gtkmm list I tried using a cell data function but those > only get called if the cell is in the scrolled view of the tree, which is > not often the case in my application. > > Any ideas would be great, thanks! > dave > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
treeview path/iter to undisplayed model item
Hi all - I have a situation in my application where I'd like to do something with an iterator/treepath that I've just added to the model. Specifically, I need to do things like get_cell_area and scroll_to_row in certain instances. It seems I am unable to get valid results out of these functions until after the tree view control has rendered them. Calling get_cell_area will give the area of a DIFFERENT cell (ack!) and scroll_to_row will simply do nothing. Is there a way to determine if an iter/treepath has been displayed or could be displayed (not in the current scrolled area of the treeview)? I don't know how else to solve my problem. Using a timeout works some of the time but since I cannot accuratly determine if the treepath I have is going to work with those functions it's more of a bandaid then a solution. As suggested on the gtkmm list I tried using a cell data function but those only get called if the cell is in the scrolled view of the tree, which is not often the case in my application. Any ideas would be great, thanks! dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: can anyone explain what is this sql query?
This seems to explain it: http://library.gnome.org/devel/libgda-4.0/unstable/GdaDataModelQuery.html#gda-data-model-query-set-modification-query dave On Mon, Aug 18, 2008 at 11:46 PM, paragasu <[EMAIL PROTECTED]> wrote: > [snip] > #define CONTENTS_DEL_SQL "DELETE FROM order_contents WHERE order_id = > ##oid::gint AND product_ref = ##-0::gchararray AND quantity = > ##-2::gint AND discount = ##-3::gdouble" > [/snip] > > i take this from the official gnome-db documentation > http://library.gnome.org/devel/libgnomedb-3.0/unstable/ch04s03.html > > unfortunately, i don't know what the ##oid:gint or ##-0::gchararray or > ##-2::gint or ##-3::gdouble mean (inside the delete query). And i cannot > find > any documentation on it. i want to know what the -0, -2 or -3 mean .. > > can anyone point me a link for me to read more, i am more than happy if > anyone > can explain it to me.. thank you > ___ > 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: Sliding effect of widgets
You might want to look at clutter: http://clutter-project.org/ dave On Mon, Aug 11, 2008 at 9:38 PM, dolly vittal <[EMAIL PROTECTED]> wrote: > Hi All, > > I am developing a small GTK+ application on the lines of a media player. > When a widget replaces another widget, I need to have the sliding effect. > I have searched the GTK+ and came to know that the sliding effects are not > implemented in it. I would like to know if GTK+ themes need to be used for > the sliding effects. If the themes are to be used, it would be very > helpful if anybody could suggest a theme with that effect. Also, if GTK+ > source code needs to be changed, it would be helpful if you could give me > some pointers on where to start. > > Thanks. > > Regards, > Dolly > > > > > ___ > 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: Using g_signal_connect in class
On Tue, Jul 15, 2008 at 6:36 AM, Gabriele Greco <[EMAIL PROTECTED]>
wrote:
>
> static void handle_click_cbk(GtkWidget *mywidget_, MyClass *data) {
> data->handle_click(); }
>
You can't make a callback function intended to be used by C code be inside
of the C++ class. It will not be able to find it.
Marco, I recommend using the full gtkmm API - this mix of gtk+ and gtkmm
will lead to a lot of headaches unless you know where the boundaries of the
two are (you can use them together, but typically not in a way you are using
it now).
Read the excellent docs at http://gtkmm.org/documentation.shtml,
specifically the book at
http://gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/index.html
dave
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How do I make a gtk2+ application "swallowable"?
Hi - I wrote a small GTK dockapp that was a simple clock (since abandoned!). You can probably find all the info you need in the source itself which is quite small. http://code.l3ib.org/?p=.users/daf/ock.git;a=blob;f=ock.c;h=4d5b052ff31a2bb2e7205c5ff580e53d93564953;hb=HEAD the actual dock code I probably lifted from someone else's pet project. dave On Wed, Jul 9, 2008 at 10:12 AM, Hazel Russman <[EMAIL PROTECTED]> wrote: > Can someone please tell me how to make an application > run in "withdrawn" or "swallowable" mode so that it > can appear in the dock of certain window managers. I > have checked the gtk FAQ and the gtk Reference Guide > but have found no clear guidance, so have had to fall > back on guesswork. > > I tried using gtk_window_set_decorated to remove the > window frame and gtk_window_set_type_hint to set the > window type to GDK_WINDOW_TYPE_HINT_DOCK, but the > window still appears on the regular desktop. > > What more do I need to do? > > > __ > Not happy with your email address?. > Get the one you really want - millions of new email addresses available now > at Yahoo! http://uk.docs.yahoo.com/ymail/new.html > ___ > 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: [Usability] UI design question
On Sun, Jun 29, 2008 at 9:35 AM, natan yellin <[EMAIL PROTECTED]> wrote: > I'm curious by nature, so does your application already have a website? > This is something that I've always felt would be useful. > Not yet, I want to finish most of it before revealing it. I know, developing in the dark is bad, but I'd rather do it this way and finish it rather than announce a half broken project. > Regarding your question, I agree with Mathew that the noun-->verb > relationship is a bit simpler. If you decide to use the verb-->noun design, > I'd recommend hiding the "Theme Name" field until the user actually clicks > on "Create a new theme" or "Modify an existing theme." I would try to reduce > the amount of unnecessary fields and boxes whenever possible. Ok, thanks. For all in the thread, I have for the time being abandoned the "all in one" dialog - just too many concepts at once. I currently have a separate "New" and "Open" dialog, but I may revisit it in the future. Wanted to get something in place to work and see how it felt rather than endlessly planning it! thanks all, dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Usability] UI design question
Hi Matthew + Jacob - Thanks for the advice, some good stuff in here. On Mon, Jun 16, 2008 at 7:59 PM, Matthew Paul Thomas <[EMAIL PROTECTED]> wrote: > > My first thought is: That list of actions doesn't seem to include > anything that requires it to be a dialog. Could it be an ordinary window > instead? I guess I just didn't get the difference between the two. I thought a dialog was just a window with a pre-defined layout. I'm guessing by your reactions there is a bit more? > > Instead, try thinking object -> verb: present the list of themes first, > with the actions afterwards. Like this: > > This is much calmer, even while it lets you see the complete list of > themes at a glance (which the radio-button-based design wouldn't). To be honest, it didn't strike me right away, but this could be a pretty good way of looking at it. I'll fiddle with it a bit and see what looks good. Any other options for laying it out? The buttons at the bottom seem a bit.. eh, i don't know how to describe it. Would it lose anything if they were on the right, arranged vertically? > Here's what would happen to the previous options: > * "Create a new theme" -> "New...", then type its name into the >newly-created table row. > * "Create a new theme based on an existing theme" -> select theme, >then click "Duplicate..." and type the name into the newly-created >table row. > * "Open an existing theme" -> select theme, then click "Open". > * "Edit current theme" -> open window, then click "Edit" (the current >theme being selected by default). > * "Open last edited theme" -> select theme, then click "Edit...". I think the "edit" and "open" actions are really the same thing here, so they can be combined into a single button. Thinking about the (future) general users of this application, the "new from scratch" option is going to be not used very often. I think the majority of themers start off by copying something (the duplicate) and then tweaking it until it is unrecognizable, so I think the "create based on an existing" or "edit existing" are the two most important items on this menu. With the "new theme" being so prevalent, I think people will miss the functionality of "duplicate" on first glance, until they try it a few times and see what happens. I hope I'm being clear above. With this info in mind, does it change anything about what you said? Either way, thanks for this information, it's exactly the kind of stuff I was looking for. Sorry if I am not so "that's perfect!" out the gate, I'm trying to learn this stuff a bit, not just follow blind advice :) Thanks again, dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
UI design question
Hi, I'm crossposting to both the usability list and gtk app devel list, i hope this is ok, as I couldn't really see where my question fit in. I am designing a gtk application and I'm trying to follow the HIG, and I wanted to get some opinions on a "simple" dialog in the application. Here is a description (chopped out of an email i sent to a friend earlier): I've come up with 5 distinct actions this dialog should have. The actions are as follows: - Create a new theme - Create a new theme based on an existing theme - Open an existing theme - Edit current theme - Open last edited theme (the last two items will have text inserted at run time to explain what those theme names are) I thought the best way to do this was a radio button group, as it would show all the available actions neatly on one screen. The problem is, there is additional information that needs to be taken in depending on what is selected. For the top two items (both creates), a theme name must be given in a text box. For the create new based on existing and open existing, a theme needs to be selected from a list of themes. Because of these additional controls, I don't know how to lay this dialog out so that the user can see that the listbox and textbox are dependant on selections in the radio group. Another idea is to use a drop down, which could be put above the textbox/listbox, and have those go sensitive/insensitive as appropriate, but i feel that masks the user from seeing the possibilities of opening/creating themes. Yet one more idea is to use a multiple screen approach, with simple buttons that have nice icons that indiciate which action to take, and have a second dialog then ask for the required information such as a name or existing theme, but i feel multiple screens is a bit wizardy and not needed. Any thoughts? thanks all. dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Best practices for laying out controls
On Tue, May 13, 2008 at 1:58 PM, <[EMAIL PROTECTED]> wrote: > I use a GtkSizeGroup to line them up. > > http://library.gnome.org/devel/gtk/stable/GtkSizeGroup.html > John, Peter - Thanks, I didn't know about this class, so far my testing has been good with it. It's a shame it can't really be used from glade, however, keeping the interface in two places is a bit of a put off but it seems the way to get things done. Anyone else have any brainstorms on how to use something like this from glade? thanks, dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Best practices for laying out controls
Hi, I'm currently developing an application which has a lot of input widgets to it. After consulting the HIG [1], specifically the portion about Window Layout [2], it left me quite confused with exactly how I should implement the guidelines it suggests. I understand the importance of alignment and good visual flow here, but I'm not sure which containers/widgets I should be using in order to achieve a nice, aligned layout. Originally, I was using a GtkTable but I am not convinced that it is the proper container. I was led to use this by the fact that I wanted labels (in a column) to be all aligned based on the largest size of the labels, and the controls on the right (in another column) to be aligned to the left there, all making a neat line. However, working with a GtkTable in glade-3 has been a bit problematic, and I'm seeking suggestions as to how other people would lay out a dialog, using what containers, etc. I had thought about using a VBox, and then a number of HBoxes inside of the VBox, but then the labels/controls quickly go out of alignment with one another. Check this screenshot of a mockup of this scenario in glade (glade file available here [3]): http://d.minuslab.net/files/gtk-layout-test-1.png Notice how the color button and spin button controls take up more horizontal room. I played a bit with the size requests fields but they don't appear to really request a size, perhaps they are controlled by something more with the parent controls (the hbox and vbox, respectively). Doing the opposite (an HBox with many VBoxes) leads to vertical misalignment between labels and controls. Basically my question is this, given the HIG dialog in [2], how exactly is that dialog made? What lines everything up so nicely so that the labels are on the left and the input controls are in a neat line? There must be something significant that I am missing about laying out a dialog. If you want to just point me to some source or a glade file that does something similar to the HIG dialog in [2] I would be grateful as well, but an explanation would really help. Thanks, dave [1] http://library.gnome.org/devel/hig-book/stable/ [2] http://library.gnome.org/devel/hig-book/stable/design-window.html.en [3] http://d.minuslab.net/files/gtk-layout-test.glade ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Not show selection of a tree view column
On 7/26/07, Peter Clifton <[EMAIL PROTECTED]> wrote: > I love the screen-shots, but I fear doing this properly is something > which GtkTreeView can't do. > > In an application I'm working on, I would really love to use a row which > spans columns for the purpose of rendering a: > "Click here to add new field" row. > > I unfortunately ended up having to put a (much shorter) text in the > first column. > > This won't help your problem, but a possible workaround for mine is to get the coordinates of where certain rows are, and line up a widget to those coordinates OUTSIDE of the treeview. That might be my best bet. However, it was still really cool to write this renderer, maybe I'll polish it up a bit and post it if anyone's interested. dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Not show selection of a tree view column
Hi folks, Was wondering if it was possible to have a column omitted from the selection bar in a gtk treeview. I've made a custom renderer which displays a strip of an image, so you can split that image over a number of rows. It looks terrible with selection rectangles behind it, even worse with the dotted highlight rectangle that occurs when using the keyboard to focus a row. I'd like to be able to tell gtk to not select that row at all. Any ideas? Another possible idea would be that I have my custom renderer wrong, drawing on the wrong thing or wrong layer, not too sure about that. Maybe it is possible to use the custom renderer to draw the selection rectangle too? More description and (pretty?) screenshots can be found on my blag: http://d.minuslab.net/?p=43 thanks in advance. dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
