Re: Runtime errors with testglib.exe (Win32 build)
Having recently built it under Win32 (using Visual C++) I decided to run the test application (testglib.exe). Everything runs fine until I get to the File Functions test, at which point I keep getting debug assertions. That is a problem in the C library then, that it generates debug assertions for something that is perfectly legal like close(-1). Calling close() on a value that is not an open file descriptor is pointless, but not an error. But yeah, we could check that in testglib.c and don't call close() on -1. Committed and pushed to master and glib-2-26. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Runtime errors with testglib.exe (Win32 build)
On 7 Oct 2010, at 10:10, Tor Lillqvist wrote: That is a problem in the C library then, that it generates debug assertions for something that is perfectly legal like close(-1). Calling close() on a value that is not an open file descriptor is pointless, but not an error. But yeah, we could check that in testglib.c and don't call close() on -1. Committed and pushed to master and glib-2-26. Thanks Tor. I've modified the code similarly at my end. FWIW the debug version of Microsoft's close() function specifically checks that the file handle is non-negative and that it's equal to or less than the highest known file handle value. It asserts if either condition fails. The release version simply sets errno to EBADF and returns -1. My tests are now running fine except for the Warnings and Errors test where I see the following output:- Glib-Message: Not implemented: g_test_trap_fork Again, it'd be helpful to know if this is expected behaviour or if it indicates a problem with my build. Thanks. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Runtime errors with testglib.exe (Win32 build)
On 7 Oct 2010, at 10:47, John Emmas wrote: My tests are now running fine except for the Warnings and Errors test where I see the following output:- Glib-Message: Not implemented: g_test_trap_fork Again, it'd be helpful to know if this is expected behaviour or if it indicates a problem with my build. Okay I found it. It's not a build problem 'g_test_trap_fork' only gets run when G_OS_UNIX is defined. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ and my port of AMP for Windows
Hello, thank you very much for your reply. Yes, I'm sure that I'm using the precompiled libraries downloaded from GTK+ homepage. I have also tried Process Explorer, I had it already installed. So I tried it too to be sure and as I expected it is using the official binaries. In addition, the libraries compiled by me are dependant to libintl-8 and libiconv-2, while official binaries are not. I tried to test in a clean virtual machine under VirtualBox, same results. I tried to test on a different PC with a clean Windows installation, same results. BTW, with another virtual machine in VirtualBox I tried to test on Windows 2000 and it does not work. One of the DLL has dependency to functions like freeaddrinfo() in winsock2 (to be more precise, it's libgio-2.0-0.dll). Perhaps you should add somewhere in some include files: #if defined _WIN32_WINNT _WIN32_WINNT = 0x0500 #include wspiapi.h #endif where winsock2.h is included. so that if an user wants to avoid the error of missing functions like freeaddrinfo(), then he can do it at compile time by simply forcing _WIN32_WINNT to 0x0500. Of course, there are other solutions for fixing this. Perhaps I'm doing something wrong when compiling my exe file. In previous email I forgot to write about the generation of the executable. I'm using this command in a batch file: gcc test.c -o test.exe -mms-bitfields -Ic:/mingw/include/gtk-2.0 -Ic: /mingw/lib/gtk-2.0/include -Ic:/mingw/include/atk-1.0 -Ic:/mingw/include/cairo - Ic:/mingw/include/pango-1.0 -Ic:/mingw/include/glib-2.0 -Ic:/mingw/lib/glib-2.0 /include -Ic:/mingw/include/pixman-1 -Ic:/mingw/include/freetype2 -Ic: /mingw/include -Ic:/mingw/include/libpng14 -Wl,-luuid -Lc:/mingw/lib -lgtk- win32-2.0 -lgdk-win32-2.0 -limm32 -lshell32 -lole32 -latk-1.0 -lgio-2.0 - lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpangoft2-1.0 -lpangowin32-1.0 -lgdi32 - lfreetype -lfontconfig -lpango-1.0 -lm -lcairo -lgobject-2.0 -lgmodule-2.0 - lgthread-2.0 -lglib-2.0 -lintl I took the CFLAGS and the LIBS by quering pkg-config and they are the same used by AMP. I must say that I do not know what to think... changing the libraries (mine or official ones) does not change its behaviour. So I was thinking about a problem with this executable, I do not know... like some alignment differences somewhere... I ignore what it could be wrong with a so small source code but able to replicate my problem. In your message you wrote that there is no point in calling gdk_threads_init(). So: #ifndef _WIN32 gdk_threads_init() #endif is this the best solution to apply? Or, better, is there a macro to check for writing something like this? #if GDK_THREADS_ARE_SUPPORTED gdk_threads_init() #endif Now I wrote with some fantasy 'GDK_THREADS_ARE_SUPPORTED' but I'm guessing if there is one with the same behaviour. In the Audacious Media Player there are no calls to functions gdk_threads_*, there are just some calls to macro GDK_THREADS_ENTER and GDK_THREADS_LEAVE in some strategic points. In other plugins there are some calls to functions gdk_threads_enter() and gdk_threads_leave() only. But I admit I would be happy to know what hangs my executable. Thank you for the tip for closing completely the programme. Actually Audacious already quits nicely when I close the main window, so I guess there is something like you suggested hidden somewhere. But there is another thing that the player does but it should not: when I launch the programme, a textmode console is opened immediately at startup. Obviously, this happens when an application is created for working in console mode (and I'm surprised on this since entry point of the application is the main() function). With GTK+ compliant code, is there a special care to take for closing it? Or do I need to do it myself (by hiding the attached console, or creating a true startup code Windows with Winmain() that calls the main()? Thanks a lot for your time. Sincerely, Carlo Bramini. The window is created and I can interact without problem with it. Now, here you are another little test programme that does not work: It *does* work for me, both when running against GTK+ 2.20.1 and 2.22.0. (The official binaries from www.gtk.org, actually hosted on ftp.gnome.org.) window = gtk_window_new(GTK_WINDOW_TOPLEVEL); You really should add here: g_signal_connect_swapped(G_OBJECT(window), destroy, G_CALLBACK(gtk_main_quit), G_OBJECT(window)); (or something to the same effect; there are several ways to do it) so that the program ends when the window is closed. (This is not to be related to the problem you are seeing, the program worked for me even if I didn't add this, the problem then was just that when I closed the window the program didn't exit.) The window is created, it's visible on the screen but it's freezed, I cannot interact with it and its content is never updated (the busy cursor is always shown on top of the window). Sorry, but I don't see this happening. Have
scrollbar of non-standard size
Hi! At first, sorry for my English. In my application I need to do a scrollbar of a bigger size than in standard case. I.e. all the elements of a scrollbar - arrow buttons and a slider must be of a bigger size. Can you suggest the better (or the easiest) way to do this? Thanks in advance. Stepan. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: multiroot-filechooser ready for merging
On Wed, 2010-10-06 at 16:24 -0500, Federico Mena Quintero wrote: On Wed, 2010-10-06 at 21:01 +0100, Bastien Nocera wrote: Symbolic links? To both the filesystem itself, and to directories under ~/.gvfs/. Are those blocked as expected? Looks like we have different expectations ;) Then I would play down the security benefits of the features in the documentation... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Wed, Oct 6, 2010 at 3:06 PM, Federico Mena Quintero feder...@ximian.com wrote: Hi, all, I've been running Christian Hammond's multiroot-filechooser branch for about a month now, with zero ill effects. This is not surprising, as no apps actually use the multirooting functionality yet; what is nice is that those apps haven't broken yet. The past discussion is in bug #609886. I took the original multiroot-filechooser-2-20 branch and rebased it on top of master, and pushed the result as a new multiroot-filechooser branch. This is ready for merging into master, for 3.0. Hey Federico, I've committed some fixes to the branch to make it actually build. After that, I played for 5 minutes with testfilechooser. The general functionality of hiding out-of-root stuff seems to work fine, but the completion in the entry has issues. When rooted to $HOME and /tmp, I found that typing '/' would still complete all toplevel directories, while typing '/t' comes up with no completions. I would have expected just '/tmp' in both cases. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
Hi, Oh, I see now it's a WrapBox replacement I guess (reading threads out of order) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
I think a picture would be helpful ;-) Are we sure this is of general interest? It seems like something only a few percent of apps would end up using. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
Oh, another thing to have is probably h-spacing and v-spacing for the grid-wide space between rows and columns. For per-column or per-row spacing you could use a margin or a spacer widget placed on that row (?) If not clear the idea of the exercise I was doing is to figure out how you'd naturally describe a layout, say to another person, in logical terms and without redundancy. So examples of things I think you would not do if talking to a person or just thinking logically include: * doing the pack_end widgets backward * positioning widgets using grid coordinates One litmus test for too much redundancy is if you have to change two lines to add or remove a widget. I think to put another widget on a row or to add another row, you should be able to add one line of code without changing other lines, at least in the typical case. Similarly to remove a widget or row, you should just delete the corresponding line of code. GtkTable requires you to change both the table constructor (overall table size) and _then_ possibly re-number a bunch of the other children, so it epic fails this litmus test. Another idea, the cursor thing could be done explicitly: GtkGridCursor cursor; gtk_grid_cursor_init(grid, cursor, row=0); gtk_grid_add_row(grid, cursor, child); But it seems like extra typing for not much good reason. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
On Thu, Oct 7, 2010 at 9:23 AM, Havoc Pennington h...@pobox.com wrote: Hi, I did a little exercise a while ago of screenshotting some apps that seemed to be doing moderately complex layout and trying to write down what would be intuitive / no-redundant-typing sequences of commands to pack the layouts. Don't know if this will make sense to anyone else but I do think it's useful to take some real-world layouts and see how much typing they'd require and how clear the resulting code is. I didn't really finish the exercise so there's probably some mistakes in here. Some preliminary theories from the exercise: some nice stuff. one thing that comes to mind is the question of what child reordering actually does in such a world. if its not clear why i think that is a question to be answered, i'll expand ... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom trista...@openismus.com wrote: However I would really appreciate it if a widget's placement inside a container can still be clearly introspected and defined with container child properties (in other words I think the widget should be built with child properties and the 'cursor' be a convenience API layer of sorts). To me, what Havoc described really sounds like a layer of convenience api or 'gridbuilder' on top of a widget that has child properties similar to what my GtkGrid has. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Thu, 2010-10-07 at 08:54 -0400, Havoc Pennington wrote: Hi, Oh, I see now it's a WrapBox replacement I guess (reading threads out of order) Well, not quite. This one has a fixed number of columns (or rows, depending on the orientation). That makes its layout quite different than if the number of rows was variable. I think of this one as being like newspaper columns. Here are some screenshots of tests/testspreadtable from the spread-table branch: http://www.flickr.com/photos/murrayc/sets/72157624989723865/detail/ It makes possible (dynamic) arrangements of widgets like this: http://www.glom.org/wiki/index.php?title=File:Small_glom_data_details.png Maybe it's not wanted by many people, but people ask for it every now and then. I want it myself, so I obviously have an incentive to have it maintained inside GTK+. -- murr...@murrayc.com 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: grid widget (was Re: possible removal of GtkWrapBox)
On Thu, 2010-10-07 at 10:55 -0400, Matthias Clasen wrote: On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom trista...@openismus.com wrote: However I would really appreciate it if a widget's placement inside a container can still be clearly introspected and defined with container child properties (in other words I think the widget should be built with child properties and the 'cursor' be a convenience API layer of sorts). To me, what Havoc described really sounds like a layer of convenience api or 'gridbuilder' on top of a widget that has child properties similar to what my GtkGrid has. Matthias, to reply to your previous mail about hfw management in general, I havent thought out GtkTable management in full detail (or implemented it) but here are some starting points: a.) Tabular widgets need to prioritize one of the request modes, the table either does height-for-width or width-for-height. My best guess is that it should be the majority of the request modes of it's children. Then what happens at request time becomes pretty obvious (when requesting a height-for-width table in width-for-height mode, its important to return the height-for-minimum-width), at allocation time however.. b.) At allocation time you need to actually prioritize one dimension, so you need to do the following for height-for-width: - Get the available allocated width - Gather the MAX()s of all minimum/natural sizes of widgets in a column and add them to a GtkRequestedSize array - Allocate widths using gtk_distribute_natural_allocation() - Further distribute remaining expand space if any appropriately to expanding columns - Now you have the allocated widths, go for heights... gather the MAX()s of the heights of rows taking into account the already allocated width of each column. - Naturally distribute vertical space again with gtk_distribute_natural_allocation() - Distribute remaining expand vertical space b.) It goes without saying but obviously you save alot of lines of code when writing functions that take an 'orientation' argument and are orientation independent. c.) The remaining problem becomes widgets which span several rows or columns, however there is code which can be inspected that does this, see tabular GtkComboBox menus. The approach taken there is, when asking for say, a widget that spans 3 columns' width... the minimum and natural width for that widget *for that column* is devided by 3. Widgets that span columns just take up the space that your code decided to allocate to those columns (same will go for rows). Hope this is of some use ;-) Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
Hi, On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom trista...@openismus.com wrote: However I would really appreciate it if a widget's placement inside a container can still be clearly introspected and defined with container child properties (in other words I think the widget should be built with child properties and the 'cursor' be a convenience API layer of sorts). I agree with this (and almost mentioned it). I guess what I'd say though is, I think the gridbuilder should be the primary/expected API when packing with code, and taking the API design top down, the child properties have to be designed such that the nice gridbuilder is possible. I wouldn't really do the gridbuilder as a literal separate API (gtkgridbuilder.h). I think it would add typing and confusion. I'd say go ahead and make it gtk_grid_add_left(), etc. which would be the first API people go for. And then the raw child props API could even be _just_ properties (use gtk_container_add_with_properties etc) or just a couple of low level functions that would be documented as you probably don't want to use this One question on gridbuilder is whether it's persistent. For example, it could be that as I'm doing add_left(), add_row(), etc. that is just setting fixed grid coordinates. And then once the grid is created, I can't use the gridbuilder stuff to modify it. Or, it could be that as I do add_left(), add_row(), etc. that is saving a conceptual list of actions and on each relayout, that conceptual list of actions is converted to a table of cells. I think it's maybe the second thing for two reasons: * you can then use gridbuilder API to modify the table later. an API could allow you to set the cursor to a particular row and next to a particular widget, then you start gridbuilding * you need to autocompute table size, so when doing add_left, add_row, etc. you don't know the actual cell coordinates yet It isn't totally clear to me what the right child properties are. Kind of the way I'd approach this would be to have some sample layouts that were typical and Should Be Easy(tm), write nice, logical, non-redundant code that should produce those layouts, then figure out how to implement the widget to support said nice code. Hmm. One other goal ideally achievable, is that a simple one-row box should not have a ton of CPU or memory overhead. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 07:09 -0400, Matthias Clasen wrote: When rooted to $HOME and /tmp, I found that typing '/' would still complete all toplevel directories, while typing '/t' comes up with no completions. I would have expected just '/tmp' in both cases. Good catch, thanks. I'll take care of this. Thanks for commiting the build fixes! My GTK+ 3 build setup is hosed at the moment, so I couldn't really test it - I just wanted to push the rebased version to safe place. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 00:28 +0200, Torsten Schoenfeld wrote: G_TYPE_STRV properties don't need annotations, they are handled automatically. But functions like your gtk_file_chooser_set_root_uris need to have annotations to tell gobject-introspection that 'char **roots' is actually a zero-terminated array. gtk_builder_add_objects_from_string in gtk+-3/gtk/gtkbuilder.c is an example with such an annotation. Got it, thanks. Is the list of annotations documented anywhere? The generated docs in library.gnome.org don't seem to have all the stuff from annotationparser.py (which took some code-reading to find) :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 09:59 +0100, Bastien Nocera wrote: Then I would play down the security benefits of the features in the documentation... Yeah, good point. The docs as they are just say that you can't go outside the roots, which could mean that the code tries really hard to do that. I'll fix the docs. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
On Thu, 2010-10-07 at 09:23 -0400, Havoc Pennington wrote: Don't know if this will make sense to anyone else but I do think it's useful to take some real-world layouts and see how much typing they'd require This is a very interesting exercise, and the pseudocode for those examples *is* really nice and concise. However, who writes UIs by hand these days? Doesn't everyone just use Glade? (I know, I know; we all have a complex part in $project where you need to code the layout by hand. Or you have historical hand-coded UIs. Life is hard.) I don't know how many other examples you considered while thinking about your API, but let's see about those three: 1. Gedit's about dialog. This is just GtkAboutDialog, correct? GTK+ has all the hand-coded stuff; Gedit doesn't have to worry. 2. Calculator. It's done with .ui files! There's a .ui file for each important section or mode (advanced, financial, programming), which then get put into the window. 3. Display properties. It's done with a .ui file as well! I'd love to see a list of common UI patterns that people use, or the common quirks, or the common special-cases they need to do. Here are a few: * Our HIG-beloved sections with indented contents in dialog boxes. There is no official solution to this, and various apps do different hacks to achieve them. * Groups of widgets that need to be shown/hidden, sensitized/desensitized upon different conditions. Sometimes you can get away with sticking them in the same container and just operating on the container. Other times you need to keep a hand-build list of those widgets and really operate on them by hand. What gets painful sometimes is that windows get unexpected sizing if you hide a few widgets. * Baselines!!! I think we could make things automatically look prettier if we let certain containers hang off a label's baseline. For example: Foo bar ++ Baz beep [__] || [__] || [ ] Blah || [ ] Blih bluh ++ Those are a few labeled widgets around a list widget or something equally obtrusive. GTK+ should let you guarantee that the labels on each side are aligned on their baselines, *without* requiring you to carefully sync up the spacings on both sides. Extended-layout originally had something about baselines; I don't know if this is still in the branch, or if it works at all. * Fixing the bugs like a table with an empty row still gets both spacings around the row applied - I was in the middle of fixing that one, but didn't finish. That would help when you have to hide/show widgets at runtime. I *think* Matthias's grid widget is a GtkTable with WFH that can be used in place of GtkBox, but still intended to be used from Glade, mostly. (Having a helper API like the one you propose to fill up an existing table/grid/whatever sounds nice; I just don't know if it is a lot of complexity that won't get used much in the end. Such an API would be really for code only, not something that you expect to be a GtkBuildable.) From your other mail: One litmus test for too much redundancy is if you have to change two lines to add or remove a widget. If you are making your UIs with Glade, it would help for Glade's usability to be improved in a similar fashion. We should study what kinds of tricks people use to rearrange widgets... creating a temporary window, inserting a container, then cuttingpasting widgets into it to create a holding space, is pretty cumbersome. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Writable array returned from gtk_tree_path_get_indices()
On Thu, 2010-10-07 at 09:18 -0500, Stef Walter wrote: Is the integer array returned from gtk_tree_path_get_indices() writable by design? Or should it be treated as readonly? It depends. Sometimes you get a GtkTreePath from the treeview API when you ask for something (e.g. gtk_icon_view_get_path_at_pos()). Since that is a newly-generated path that you own, you can do anything you want with it. People may use it as a counter and increment the index to iterate over the model, or whatever. Sometimes you get the GtkTreePath as an argument to a callback (e.g. GtkTreeModelForeachFunc). Generally you shouldn't modify the path in that case. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On 07.10.2010 18:14, Federico Mena Quintero wrote: Is the list of annotations documented anywhere? This is the canonical place, as far as I know: http://live.gnome.org/GObjectIntrospection/Annotations. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
Hi, On Thu, Oct 7, 2010 at 1:18 PM, Federico Mena Quintero feder...@ximian.com wrote: However, who writes UIs by hand these days? Doesn't everyone just use Glade? It's a valid point, but I don't know that Glade is always easiest. I don't think it's a good excuse for making the actual API crappy. (In fact I'd almost think Glade should have its own container widget that's designed to be easy to use in a builder, just as in code it's good to have a container widget that's easy to use in code. Do the same top-down exercise with Glade - what would make a container easy to work with in a UI builder - and design based on that.) I don't know how many other examples you considered while thinking about your API, but let's see about those three: I knew these were built into gtk and probably ui files, but I still think they're good examples of reasonably complex layouts that show some of what people want to do. * Our HIG-beloved sections with indented contents in dialog boxes. There is no official solution to this, and various apps do different hacks to achieve them. I was thinking this could be built into Grid, but it's normally done with a frame right? Which seems OK too except that Frame's defaults don't match what's wanted. Possibly needed here is a GtkBin that looks the GNOME HIG way on Linux and a windowsy/mac-y way on other platforms. If you are making your UIs with Glade, it would help for Glade's usability to be improved in a similar fashion. We should study what kinds of tricks people use to rearrange widgets... creating a temporary window, inserting a container, then cuttingpasting widgets into it to create a holding space, is pretty cumbersome. Exactly, doing an interaction design of how layout should be done in Glade, then designing a widget just for that... would be awesome. Maybe the easy-to-code widget matches the glade widget, I don't know. Not saying we'd hide the glade widget from code or hide the code widget from glade, just that it might make sense to have a widget optimized for those two cases. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 20:20 +0200, Torsten Schoenfeld wrote: This is the canonical place, as far as I know: http://live.gnome.org/GObjectIntrospection/Annotations. Perfect, thanks! Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
On Thu, 2010-10-07 at 15:05 -0400, Havoc Pennington wrote: It's a valid point, but I don't know that Glade is always easiest. I don't think it's a good excuse for making the actual API crappy. Oh, no, of course not. What I mean is that if few apps actually do complex layout by hand, then maybe it's better to spend effort in making Glade good. But I like a lot what you say below. (In fact I'd almost think Glade should have its own container widget that's designed to be easy to use in a builder, just as in code it's good to have a container widget that's easy to use in code. Do the same top-down exercise with Glade - what would make a container easy to work with in a UI builder - and design based on that.) This is very interesting. We should definitely ask the designers. Off the top of my head, here is what happens right now: 1. You sketch your UI in a napkin or some suitable fibrous material. Due to your extensive training in visual aesthetics, your UI is well-balanced, it has good use of whitespace, etc. 2. You fire up Glade. 3. You throw in some tables and boxes to contain the elements which are visually aligned in your sketch. 4. ... Hours pass ... 5. You give up as GTK+ plainly doesn't let you adjust whitespace in an intuitive way, and it is really hard to size widgets like treeviews, etc. Your UI looks halfway decent but squashed, like if you had run GIMP's zealous crop on your napkin sketch (that's the filter that removes all empty rows/columns of pixels, leaving effectively no whitespace). 6. At some point you actually run your UI against translations which change the length of the text labels, and you give up for the second time :) When using Glade, the problem is not usually figuring out the grid you need (you just throw in a table and insert/delete cells as appropriate). The problem is having to endlessly tweak all the parameters that modify how things respond to their cells. Then tweaking all the things that affect how things resize. Then realizing that whitespace is basically impossible to do. There's too much mousing around. Click on a widget. Move the mouse all the way to the properties area. Tweak tweak tweak. Move back to the UI to click on another widget. All that back-and-forth is very wasteful. OK, I'm just complaining here. It would be good to sit down together in the Summit and see how people use Glade. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: possible removal of GtkWrapBox
On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote: Hi all, With recent developments I've found that GtkWrapBox in the end is not what was needed to meet the requirements of Glom (hence the writeup of the different container... coming in another mail). Furthermore, the gimp's newer versions is now using GtkToolPalette in place of the older wrap-box (the gimp had been using a similar wrap-box widget to wrap items around in one of it's toolbars). GIMP is still using the horizontal wrap-box in two other places. But at least one place (GimpContainerGridView) should really be rewritten. So I don't think we have a strong interest in having wrap-box functionality in GTK+. But we would like to see a grid widget that we can use for showing things like brushes in a grid-view. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Writable array returned from gtk_tree_path_get_indices()
Hi. 2010/10/7 Stef Walter stef-l...@memberwebs.com: Is the integer array returned from gtk_tree_path_get_indices() writable by design? Or should it be treated as readonly? You should definitely not modify values in returned array, since this central part of GtkTreePath. Currently, modifying parts of this array is the same as moving your path using gtk_tree_path_(next|prev)(), but if internal structure of GtkTreePath changes, you'll be in trouble. Some stuff like GtkTreeModelSort and GtkTreeModelFilter write to this index array, but those may be liberties taken by gtk+ internally. Quickly looking at the code I would say that this is indeed the case here. Directly modifying values avoids some type checking, which speeds up some of the operations. Perhaps we would change the return values for the following to 'const gint*': gtk_tree_path_get_indices () gtk_tree_path_get_indices_with_depth () If not by design, I'll file a bug, and patch. I think that minimal thing to do here is to update docs to something like this: Returns the current indices of path. This is an array of integers, each representing a node in a tree. This value should not be freed and members of array should not be modified. Filling a bug is definitely the way to go IMHO. Cheers, Tadej -- Tadej Borovšak tadeboro.blogspot.com tadeb...@gmail.com tadej.borov...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Writable array returned from gtk_tree_path_get_indices()
On 2010-10-07 16:29, Tadej Borovšak wrote: You should definitely not modify values in returned array, since this central part of GtkTreePath. Currently, modifying parts of this array is the same as moving your path using gtk_tree_path_(next|prev)(), but if internal structure of GtkTreePath changes, you'll be in trouble. That's true, unless GtkTreePath is essentially a gint array, and exposed as such. This concept would be part of the ABI, and the internal structure could never be changed. I guess that was the essence of my question. Is that the case? I think that minimal thing to do here is to update docs to something like this: Returns the current indices of path. This is an array of integers, each representing a node in a tree. This value should not be freed and members of array should not be modified. The best way of documenting 'don't modify' is to const the return value. I've done both in my patch. Filling a bug is definitely the way to go IMHO. Here it is: https://bugzilla.gnome.org/show_bug.cgi?id=631659 Cheers, Stef ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: grid widget (was Re: possible removal of GtkWrapBox)
On Thu, 2010-10-07 at 14:37 -0500, Federico Mena Quintero wrote: On Thu, 2010-10-07 at 15:05 -0400, Havoc Pennington wrote: It's a valid point, but I don't know that Glade is always easiest. I don't think it's a good excuse for making the actual API crappy. Oh, no, of course not. What I mean is that if few apps actually do complex layout by hand, then maybe it's better to spend effort in making Glade good. But I like a lot what you say below. (In fact I'd almost think Glade should have its own container widget that's designed to be easy to use in a builder, just as in code it's good to have a container widget that's easy to use in code. Do the same top-down exercise with Glade - what would make a container easy to work with in a UI builder - and design based on that.) This is very interesting. We should definitely ask the designers. Off the top of my head, here is what happens right now: 1. You sketch your UI in a napkin or some suitable fibrous material. Due to your extensive training in visual aesthetics, your UI is well-balanced, it has good use of whitespace, etc. 2. You fire up Glade. 3. You throw in some tables and boxes to contain the elements which are visually aligned in your sketch. 4. ... Hours pass ... 5. You give up as GTK+ plainly doesn't let you adjust whitespace in an intuitive way, and it is really hard to size widgets like treeviews, etc. Your UI looks halfway decent but squashed, like if you had run GIMP's zealous crop on your napkin sketch (that's the filter that removes all empty rows/columns of pixels, leaving effectively no whitespace). 6. At some point you actually run your UI against translations which change the length of the text labels, and you give up for the second time :) When using Glade, the problem is not usually figuring out the grid you need (you just throw in a table and insert/delete cells as appropriate). The problem is having to endlessly tweak all the parameters that modify how things respond to their cells. Then tweaking all the things that affect how things resize. Then realizing that whitespace is basically impossible to do. There's too much mousing around. Click on a widget. Move the mouse all the way to the properties area. Tweak tweak tweak. Move back to the UI to click on another widget. All that back-and-forth is very wasteful. OK, I'm just complaining here. It would be good to sit down together in the Summit and see how people use Glade. Maybe this is a good time to revive my pet composite containers branch[0]... I've tried to explain this a hand-full of times, hopefully by now it's understandable in detail in the bug report[1]. Generally, the way that *I* would like people to use Glade is a little more like adobe flash or the NextStep Interface Builder... that is to say... you go ahead and design an interface and then break it down into sub-ui files... each UI file can be implemented as a composite widget class (i.e., right-click on your user information box full of entries and Export As Class, then write your FooUserInformation widget which will show up inline in the main UI... copy/paste/reuse at will... in your language binding of choice, exported named composite children show up as object properties/instance-members auto-magically). So far the branch transforms most of the internal dialogs to use GtkBuilder xml to define the UI (i.e. GtkAboutDialog is *not* a special-case with hand-written code anymore... it's defined with it's own .ui file). When I last touched this pet branch of mine a few months ago I think the final thing lacking was to update the GTK+ build system so that header files can be generated for the .ui files (currently the xml is declared as a string constant inside the dialog widget classes themselves which is a little awkward for editing with Glade, however ultimately they should be included as a string constant to avoid scratching the hard-disks just to create/show a dialog). Cheers, -Tristan [0] http://git.gnome.org/browse/gtk+/log/?h=composite-widget-templates [1] https://bugzilla.gnome.org/show_bug.cgi?id=612036 Note on Glade, With all the big plans for Glade and short amount of time I've had in the past (I've always been a little over-ambitious I guess), I think I will have to drop support for libglade and GTK+2.0's deprecated widgets completely... and then we can focus on doing a really rocking Glade for GTK+ 3.0... another big focus will be better interaction in the workspace, this should be much improved by rendering all the project widgets offscreen and allowing us to paint on top of them with cairo directly. Federico ___ 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
