Re: GTK+ 2.24.8
http://download.gnome.org/sources/gtk+/2.24/ ftp://ftp.gnome.org/pub/GNOME/sources/gtk+/2.24/ * Win32 updates: Major update of the win32 backend, it now works at least as well as the old 2.16.x version that a lot of windows applications was forced to use Anyone has a prebuilt package with all the dependencies like the 2.16 and 2.24.0 bundles available in the gtk.org website or a cross-build script to build them through mingw32, I'd like to try my various win32 projects, all stuck at 2.16.x, with 2.24.8 but I have no time frame at the moment to build everything from scratch :( -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.24.8
On Fri, 11 Nov 2011, Gabriele Greco wrote: http://download.gnome.org/sources/gtk+/2.24/ ftp://ftp.gnome.org/pub/GNOME/sources/gtk+/2.24/ * Win32 updates: Major update of the win32 backend, it now works at least as well as the old 2.16.x version that a lot of windows applications was forced to use Anyone has a prebuilt package with all the dependencies like the 2.16 and 2.24.0 bundles available in the gtk.org website or a cross-build script to build them through mingw32, I'd like to try my various win32 projects, all stuck at 2.16.x, with 2.24.8 but I have no time frame at the moment to build everything from scratch :( Me too! It would be great to have updated packages on gtk.org. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK3 and MS-Windows theme
Does GTK3 contain the win32 work that was just released with 2.24.8? My GTK3 app doesn't display using the MS-Windows theme, even when I specify it in the etc/gtk-3.0/settings.ini file. Under Windows XP or Windows 7 it uses an ugly gray theme with hard square buttons. Thanks, Michael ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: RFC: Model-View-Controller
Hi Benjamin, I am sorry but this sounds like a lot of things, but not like a plan. - are our widgets a more-or-less huge mess? yes. - do we need to do something about it? yes - is MVC a well tested way to improve things? yes - does it always work? NO Sorry, but you are actually stating the obvious here, but fail to provide *any* example, outline, not even a simple diagram. Without any small example-ish thing to see what you mean here, this is pretty much hot air :( But I surely don't want to sound discouraging, please give a small example. Regards, --Mitch On Wed, 2011-11-09 at 19:12 +0100, Benjamin Otte wrote: Hey, so I've been thinking about this for a bit, and I think it's a good idea, but I wanted to see if other people have an opinion about it. And I wanted to get it into people's minds before we sit down for a hackfest. So this idea is a result of the mainly the following things: - Clutter integration Clutter has the concepts in some form or another. It doesn't use the definitions I'm about to use, but it has the objects I want. - widget complexity Our widgets - even the simple ones - are hellishly complex objects. Without reorganization of the code they'll get unwieldable. Here's the 5-digit source files in the gtk sources: 10464 gtkfilechooserdefault.c 10482 gtkentry.c (10947 gdkwindow.c) 13857 gtkwidget.c 16439 gtktreeview.c We need a way to make that code readable again. Also, those files generally have lots of interactions and a high cyclomatic complexity[1], which makes it hard to understand what they do. This in turn leads to people being afraid of touching them. And that starts a vicious cycle. - functionality duplication A lot of widgets duplicate functionality. Treeview and iconview have rubberbanding. Entries have progress bars and icons. Notebooks, treeviews, expanders and whatnot have buttons. We do not only duplicate the code here, but also behavior and policies. So if we decide to change the states on buttons or the way rubberbanding does autoscroll, we need to fix all of the widgets individually. And as we are currently in a process of reinventing large parts of the toolkit - both for UI design and for form factor reasons, we need to be able to change these things quickly. And currently we can't even get rid of underallocations. So what am I actually talking about? I'm proposing a Model-View-Controller split for widgets.[2] I want to split the source code for widgets into three parts. This is mostly an internal cleanup and should not affect applications that use widgets. It would however change the way widgets are coded. So this is mostly relevant for our own gtk/ directory, but would also be interesting for other widgets ike the evo calendar, EMap, the WebKitWebView, GtkSourceView, you name it. The first thing I want to do is to create View objects. So instead of having a huge draw() function, the widget would create a bunch of View objects. We would provide a few common ones (probably one per gtk_render_foo() function we currently have) and widgets would put them where they belong in the size_allocate() function. After that, they would take care of drawing themselves and all the stuff associated with looking cool based on CSS and their surroundings. In Clutter terms this is what ClutterActor is. Of course, they would probably provide other information, too, like sizing or the actual layout of text. And once we have that, we can attach additional information to these objects, like animation state, effects, caches and so on without the widgets having to care. The second thing I want to is create Controller objects. So instead of having input events handled on the widget, we add a bunch of controllers to the widget that take care of handling events and emitting signals for when the user did interact with the widget. These would go from very simple things like click, doubleclick or scroll controllers to more complex things like rubberband or dnd controllers. The Clutter equivalent here is ClutterAction. Of course, the actions will probably require a bunch of properties and will also emit quite some signals that widgets will use, but they can do things like keeping track of the device they're interacting with and things like that. And once we have that, we can attach lots of new controllers, like gesture controllers, or even switch controllers based on input method used. And of course, we have less place where we can control things like dnd threshold, double-click time, rubberband and dnd scrolling speed and gesture definitions. That leaves the widget itself as the Model (I think the correct term would be Application in the MVC context here, but bear with me, this makes it sound cooler). So the widget's job moves further away from GDK (or Cairo, Clutter or whatever the backend is) and more into the realm of being the manager between the application and the person in front of the screen. It
Re: RFC: Model-View-Controller
On Fri, Nov 11, 2011 at 2:47 PM, Michael Natterer mi...@gimp.org wrote: Hi Benjamin, [snip typical German ecouragement talk] please give a small example. (disclaimer: just to illustrate the idea, might change a lot) So, a GtkButton is kinda complex from the input perspective, but simple for drawing. It would have these Views: - Background - Child It would inherit those from GtkBin, so it wouldn't have any drawing code at all. And it'd have those Controllers: (- Hover) - Click - Activate (- Focus) - KeyPress/Release Not sure if hover and focus should be default or separate controllers. What they'd do is toggle the :focus and :hover state on the widget and nothing else. The click controller would capture mouse presses, take a grab, and on release it'd make the button emit clicked. Same as the KeyPress/Release controller (which would only capture space, return and whatever else activates a button). And the Activate controller would respond to gtk_widget_activate(). A GtkLabel would have these Views: - Background (or not - it'd have it in GTK4, maybe not in GTK3, where labels have no background) - Text and it'd have probably these Controllers: - Rubberband - Click - DoubleClick - Drag - KeyPress/Release I wanted to call Rubberband Drag, but that'd confuse people with DND. What I mean is pressing the mouse, holding it and releasing it elsewhere. Consider the name a work in process. All of them would only be active if the label was selectable. Rubberband would be used to do a selection, drag would allow DND'ing the selected text. The KeyPress/Release controller(s) would be used for the general selection handling in text, as would the Click and DoubleClick ones. (I suppose we would have one that'd be shared between all the text-handling widgets that ensured all our keybindings were identical and the selection behavior consistent - try double-clicking between words in different widgets for some fun.) Now for some fun widget, the notebook. We'd have these views: - Background - Child (for the active widget) - per action and arrow button: - Background - Icon per tab: - Background - Child And these actions: - Drop (for tabs maybe?) - per action and arrow button: - Click - Focus - Hover - KeyPress/Release - per tab: - Click - Focus - Hover - KeyPress/Release - Drag (to drag tabs elsewhere) - Drop (for tabs) - Activate (for keybindings) - per close button on the tab: - Click - Focus - Hover - KeyPress/Release You would probably be able to limit actions to certain areas/views of the widget, so the hover/focus actions would be setup to only apply to the ones they are about. It'd at least solve all our bugs with focus, hover and whatnot not working properly on notebooks that get filed and fixed regularly. Or we would make the notebook have real buttons, at which point the actions would be setup by the button. Then we'd just have to solve attaching the DND actions to the button. But with such an approach, the notebook code would look less scary (apart from the setup code...). We'd just move some views around in size_allocate and connect some signals and that'd be that. I'm not even going to try to imagine the setup for the treeview here... That said, you can see that the number of different views and controllers is quite small. It's just that we duplicate their functionality over and over and over again. And you can maybe start to imagine what would happen when people started adding gestures etc to the notebook code... Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Change in FileChooser behavior
Hello List, I recently upgraded GTK+ version 2.24.7 and discovered that the behavior of the FileChooser has changed. This change makes FileChooser very inconvenient to use. Previously, the file selection dialog would automatically show the files in the current working directory. Now, the file selection dialog automatically lists Recently Used files, and there is no option to select the current working directory. Apparently I am setting up my FileChooser incorrectly. How to I set up FileChooser so that it provides me with an option to look in the current working directory? I see that there is a member function add_shortcut_folder that I could use to add the current working directory as a shortcut folder (but then I would have to mess around with C's getcwd() function). But I didn't need to explicitly set the current previously. Is it a requirement that I explicitly set it now? If so, why was this change made? It seems this should be a simple thing. What am I missing? Thanks. Jim Tilton Dr. James C. TiltonVoice: 301-286-9510 NASA Goddard Space Flight Center FAX: 301-286-1776 Mail Code 606.3E-Mail: james.c.til...@nasa.govmailto:james.c.til...@nasa.gov (Computational Information Sciences and Technology Office) Greenbelt, MD 20771 URLs: http://ipp.gsfc.nasa.gov/ft_tech_rhseg.shtm and http://science.gsfc.nasa.gov/606.3/TILTON/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Change in FileChooser behavior
On Fri, 2011-11-04 at 15:47 -0500, Tilton, James C. (GSFC-6063) wrote: Hello List, I recently upgraded GTK+ version 2.24.7 and discovered that the behavior of the FileChooser has changed. This change makes FileChooser very inconvenient to use. Could you 'CC me on this, as I too am finding the new behaviour infuriating, and have received lots of complaints about it from users of the software I develop. gEDA CAD tools are very often started from the command line, and rely on the current working directory to pick up project config etc. This means we change the current working directory the location containing the user's current design. Users have been quite frustrated to find the file chooser doesn't default to CWD any more. I can see that for applications started from a GUI, they might not set a sensible CWD for the file-chooser to look in, but in our case - we do. I believe there will be an easy workaround, such as forcing the file-chooser to start in the desired directory from inside my program, but I would prefer to avoid doing this if possible - as it could cause inconsistencies in behaviour with the rest of the desktop. Is there a global option somewhere to switch back to the old behaviour? Could anyone point me at the commit which changed the behaviour, or a thread where this feature was discussed. I'm curious to know the rationale behind it before I start trying to hack around it. It might be that other bugs or incomplete features are making the file-chooser less usable, and that this change was part of a grander plan to make things better. Best wishes, -- Peter Clifton pc...@cam.ac.uk signature.asc Description: This is a digitally signed message part ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
help
___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Change in FileChooser behavior
Hi James, On 4 November 2011 20:47, Tilton, James C. (GSFC-6063) james.c.til...@nasa.gov wrote: Apparently I am setting up my FileChooser incorrectly. How to I set up FileChooser so that it provides me with an option to look in the current working directory? I do something like this as I build the file chooser: char *cwd; cwd = g_get_current_dir(); gtk_file_chooser_add_shortcut_folder( GTK_FILE_CHOOSER( filesel-chooser ), cwd, NULL ); g_free( cwd ); Then the cwd appears somewhere around the middle of the 'places' list on the left. It would be ncie to be able to give a symbolic name for the shortcut (eg. Current directory) since the actual dirname is often not very useful (for me, for example, it often simply comes up as data, rather unclear). John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
