DTDs and other fun
Ryan asked me to look at the DTDs for the menu markup and GtkBuilder interface definitions, since he merged everything over to GtkBuilder. Here's the old menumarkup.dtd: http://git.gnome.org/browse/glib/tree/gio/menumarkup.dtd?id=4e9f59bff8adc59fd8fde5bdee9879b8c3e4e55b And here's what our docs say the current GtkBuilder DTD is, though we don't have a separate DTD file. http://developer.gnome.org/gtk3/3.3/GtkBuilder.html#BUILDER-UI Issues: 1) The GtkBuilder DTD doesn't specify attribute types in ATTLIST declarations, so it's invalid. 2) You can't just use ANY anywhere to mean ANY. You either use ANY, or you use an element pattern. 3) If you use ANY, DTDs still try to validate those contents, and that just doesn't work because we can't specify every last element name somebody might use. In short, it is impossible to properly validate these files using DTDs. I've attached a DTD that will validate only those files that don't use any extensions. That at least serves as a sort of loose description of the format. Now, we can actually properly validate using RELAX NG. I've attached RELAX NG schemas in both the XML and the compact syntaxes. XML is the only syntax understood by 'xmllint --relaxng'. Compact syntax is more readable for humans, and it's understood by emacs nxml-mode to give you validation on the fly. See this page for tips on that: https://fedoraproject.org/wiki/How_to_use_Emacs_for_XML_editing -- Shaun gtkbuilder.dtd Description: application/xml-dtd gtkbuilder.rnc Description: application/relax-ng-compact-syntax gtkbuilder.rng Description: XML document ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DTDs and other fun
On Thu, 2012-01-26 at 17:01 -0500, Matthias Clasen wrote: On Thu, Jan 26, 2012 at 3:25 PM, Shaun McCance sha...@gnome.org wrote: Ryan asked me to look at the DTDs for the menu markup and GtkBuilder interface definitions, since he merged everything over to GtkBuilder. Here's the old menumarkup.dtd: http://git.gnome.org/browse/glib/tree/gio/menumarkup.dtd?id=4e9f59bff8adc59fd8fde5bdee9879b8c3e4e55b And here's what our docs say the current GtkBuilder DTD is, though we don't have a separate DTD file. http://developer.gnome.org/gtk3/3.3/GtkBuilder.html#BUILDER-UI Issues: 1) The GtkBuilder DTD doesn't specify attribute types in ATTLIST declarations, so it's invalid. 2) You can't just use ANY anywhere to mean ANY. You either use ANY, or you use an element pattern. 3) If you use ANY, DTDs still try to validate those contents, and that just doesn't work because we can't specify every last element name somebody might use. In short, it is impossible to properly validate these files using DTDs. I've attached a DTD that will validate only those files that don't use any extensions. That at least serves as a sort of loose description of the format. The fact that nobody ever reported the missing attribute types probably shows you how important it is in practical terms for us to ship a technically valid DTD... nobody is using this dtd for anything. I mostly agree with that. It certainly means nobody is validating these files at build/install time. The question is, should they? People don't usually put that stuff in their Makefiles unless you make it easy for them. It comes down to whether there's a high rate of invalid .ui files being installed. I kind of suspect no, because they're almost always machine-generated. With menu files written (for now) by hand, that might be different. Of course, having an invalid DTD in the docs (and another one for GtkUIManager, incidentally) isn't good. If nobody cares about the DTD per se, maybe we should look at less 1980s ways of conveying the grammar. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: i18n of app menus
On Mon, 2012-01-23 at 06:36 -0500, Matthias Clasen wrote: On Sun, Jan 22, 2012 at 3:13 PM, Olav Vitters o...@vitters.nl wrote: How can those app menus be translated? Is anyone on the gnome-i18n mailing list? The same way gtkbuilder xml files can be translated. Specify the domain when loading the xml file, and put the strings into your mo file. You can use intltool with the usual _-prefixing convention for attribute names. That's not the way GtkBuilder XML files have been translated. The strings were extracted using intltool's glade mode, not xml mode. This extracts the contents of any element with translatable=yes. But now instead of translatable strings being in the contents of marked elements, they're in attribute values. From epiphany: http://git.gnome.org/browse/epiphany/plain/data/ui/epiphany-application-menu.ui (BTW, GMarkup might accept those less-than characters in attribute values, but they're not well-formed XML.) We could translate these ui files using intltool's xml mode, but then we need an extra step to strip the leading underscore, even though we're not merging translations back into the XML. Also, I assume these files are hand-written now, but Glade will learn to output new-style menus eventually, and it's probably not going to output mangled XML. The best thing would be if menu definitions used the same way of marking strings translatable as everything else. The second best thing would be to teach intltool's glade mode to handle these translatable attribute values. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: i18n of app menus
On Mon, 2012-01-23 at 09:11 -0500, Shaun McCance wrote: On Mon, 2012-01-23 at 06:36 -0500, Matthias Clasen wrote: On Sun, Jan 22, 2012 at 3:13 PM, Olav Vitters o...@vitters.nl wrote: How can those app menus be translated? Is anyone on the gnome-i18n mailing list? The same way gtkbuilder xml files can be translated. Specify the domain when loading the xml file, and put the strings into your mo file. You can use intltool with the usual _-prefixing convention for attribute names. That's not the way GtkBuilder XML files have been translated. The strings were extracted using intltool's glade mode, not xml mode. This extracts the contents of any element with translatable=yes. But now instead of translatable strings being in the contents of marked elements, they're in attribute values. From epiphany: http://git.gnome.org/browse/epiphany/plain/data/ui/epiphany-application-menu.ui So I just read this: http://developer.gnome.org/gio/2.31/gio-GMenu-Markup.html It turns out this: item label='_New Window' action='app.new' accel='lt;Primaryn'/ is really shorthand for this: item attribute name='label'_New Window/attribute attribute name='action'app.new/attribute attribute name='accel'lt;Primaryn/attribute /item or presumably this: item action='app.new' accel='lt;Primaryn' attribute name='label'_New Window/attribute /item And attribute elements can have the translatable attribute, so we really ought to be writing this like this: item action='app.new' accel='lt;Primaryn' attribute name='label' translatable='yes'_New Window/attribute /item And then we can use intltool's glade mode and not do terrible hacks to our XML files. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On Fri, 2011-12-09 at 09:14 -0500, Ryan Lortie wrote: The bad news is this: I don't expect this to be supported on a per-application basis or to be possible to use at all from the menubars of an application. We need to make sure menus will continue to work on all platforms (including the mac and unity -- which will both display your menus in a different place, not even using Gtk in the case of the mac). This means that you will only be able to use a minimum baseline level of functionality (labels, checks, radios, accels, icons, etc.) in the normal menubar and application menu of your program. I find it extremely unfortunate that GTK+ will be restricted to using the least common denominator. That's the kind of thing you get from wrapper libraries like wxWidgets. In particular, from what I can tell, it means the searchable help menu work I did will be entirely impossible to rebase on this. Although do note that Mac OS has had that exact functionality for years. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: boxes
On Wed, 2011-11-16 at 19:01 +0100, Benjamin Otte wrote: So, next idea. I'm pretty sure about this one actually and have talked to it with people on IRC a lot. Again I have no idea how it will look in detai, but I know I want to get there. This one is all about layouting complex widgets. It again has nothing to do with the public API or ABI of GTK and is all about structuring our internal code. Well, it is about theming. The thing you want to have read or at least have heard about are these 2: box model: http://www.w3.org/TR/CSS21/box.html visual formatting: http://www.w3.org/TR/CSS21/visuren.html In particular the first. If we want to allow people to really style widgets with CSS, the widgets need to behave like CSS boxes. [snip] While we're at it, we also need to get rid of all the old style properties we had and make sure they can be sanely replaced by CSS we support. Just a small bit of input: There's nothing in CSS like GtkBox::spacing. I really wish there were. I can't tell you the number of times I've set margin-top on children and overridden it on :first-child to accomplish what GTK+ makes easy. Please let's not lose that. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
More work on GHelp API
Hi all, I posted about the GHelp API I'm working on back in April: http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00141.html I started working on this again. I've got all my work on gitorious, so I don't have to pass tons of patches around. https://gitorious.org/ghelp To test this out: * Build and install the ghelp branch of my glib repository. * Build and install the master branch of my gnomehelp repository. * Copy the .page files in gnomehelp/gnome-help into ~/.local/share/gnome/help/gnome-help/C/ * Build the ghelp branch of my gtk repository. In the gtk repository, run tests/testhelpbutton like so: ./tests/testhelpbutton ghelp:gnome-help Put any valid tag name the text entry and watch what the button and menu do. Try mouse or a11y as tags, or index as a tag that only has one page. Or grep for 'tag' in the page files. I'd like input on this API: https://gitorious.org/ghelp/glib/blobs/ghelp/gio/ghelp.h https://gitorious.org/ghelp/glib/blobs/ghelp/gio/ghelpactiongroup.h Right now, GHelp is an interface with methods the query the source. These return GHelpActionGroup instances. These are GActionGroups, but they also have a title associated with each action. I have three different ideas on how the API could be different: 1) Leave everything as it is, but make GHelp be a GHelpActionGroup. That would provide a way to ask for all pages/actions. 2) Remove GHelpActionGroup and make GHelp be a derived interface of GActionGroup. The query functions would return GHelp instances. You'd then be able to chain an indefinite number of list_for_tags and search calls. While powerful, I don't know that it's needed, and it adds complexity to implementations. 3) Remove GHelpActionGroup and make GHelp be a derived interface of GActionGroup, but make list_for_tags and search just return gchar**. That is, the GHelp object is the only GActionGroup you use, and the select functions just return a filtered list of the possible actions. I'm liking this idea. Also, I realize that the search entry in the menu is pretty crappy at the moment. It sort of works, but it does a lot wrong. This is not something GtkMenu was designed for, and it will take a log of work to get it right. It could be punted, though. The tag-based help querying alone is still cool. Comments? -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Fri, 2011-05-27 at 17:09 -0400, Havoc Pennington wrote: Hi, Man, how many times has this thread happened? At least fifty. On Fri, May 27, 2011 at 10:57 AM, Shaun McCance sha...@gnome.org wrote: try: load_some_extension() except: warn(This extension sucks. I'm disabling it and moving on.) Of course, GLib is C. We don't have exceptions. We have GError, which is a decent foundation for exceptions in language bindings. But if we don't use it, then languages that could otherwise do the right thing are screwed. This is the core thing. People who expect no g_error/abort are used to languages with exceptions. The thing that's different about C is that an exception (think GError) changes the function signature of that function... _and_ *all callers* in any library or app! I really don't want to carry this thread much further. It is getting bike-sheddy. We disagree. I'm not the one making the decisions. Life goes on. But I want to point out that my point was never that GLib should behave like a language with exceptions. Just that it should let bindings in those languages behave like they should. What I would do (take it or leave it, and let's move on with our lives) is make the constructor return NULL if there's a problem and make all consumers of GSettings abort if passed NULL. Same effect, just perhaps delayed. I don't think it risks any more data loss than the current behavior. The advantage is that bindings could do a NULL check and raise an exception. With introspection-based bindings, this kind of NULL-check-and-raise can even be done automatically, perhaps with a flag like raise-on-null. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Fri, 2011-05-27 at 15:34 +0100, Emmanuele Bassi wrote: On 2011-05-27 at 14:59, ecyrbe wrote: and then what? abort the application? gracefully terminate with a warning on the console? No, you can gracefully show a popup to the user that something is broken and to the right direction. It's better than crashing. and what would a popup solve from the user's perspective? a missing schema is a missing file, which means an installation problem. there is *no* graceful way to handle that. If the application itself is missing files it needs (schemas, ui files, .la files, whatever), then yeah. If it's some plugin that's busted, this is how I'd write my application code in a language with real exception handling: try: load_some_extension() except: warn(This extension sucks. I'm disabling it and moving on.) Of course, GLib is C. We don't have exceptions. We have GError, which is a decent foundation for exceptions in language bindings. But if we don't use it, then languages that could otherwise do the right thing are screwed. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Fri, 2011-05-27 at 17:02 +0100, Emmanuele Bassi wrote: On 2011-05-27 at 10:57, Shaun McCance wrote: On Fri, 2011-05-27 at 15:34 +0100, Emmanuele Bassi wrote: On 2011-05-27 at 14:59, ecyrbe wrote: and then what? abort the application? gracefully terminate with a warning on the console? No, you can gracefully show a popup to the user that something is broken and to the right direction. It's better than crashing. and what would a popup solve from the user's perspective? a missing schema is a missing file, which means an installation problem. there is *no* graceful way to handle that. If the application itself is missing files it needs (schemas, ui files, .la files, whatever), then yeah. If it's some plugin that's busted how do you propose to define the difference between a plugin running in the application space and an application? from a library perspective, and from an application perspective, application + plugin and application are exactly the same thing. If I were writing a native Python library, I would never sys.exit on errors. I would always throw exceptions. The library wouldn't distinguish between core and plugin, but throwing exceptions allows the core to be written in such a way that it can manage bad plugins. Of course, GLib is not a native Python library. But when underlying libraries do things like this, it makes it hard for bindings to behave the way they should. this is how I'd write my application code in a language with real exception handling: try: load_some_extension() except: warn(This extension sucks. I'm disabling it and moving on.) load_some_extension() *should* check if a schema exists in the current path, and raise an exception if not found. Ryan is working on being able to define custom search paths as well. Then load_some_extension has to know the schemas that each extension uses ahead of time, or it has to rely on each plugin being good about checking its schemas. And the ui files. And its data files. And $deity knows what else. The point is to be able to write an application that can continue to work in the presence of a piece-of-shit plugin. (BTW, how does one check a schema? I don't see any API for that.) but once you reached g_settings_new() then there's nothing you can do because anything after that assumes that the GSettings returned exist and maps to a valid settings backend, with valid values. Of course, GLib is C. We don't have exceptions. We have GError, which is a decent foundation for exceptions in language bindings. But if we don't use it, then languages that could otherwise do the right thing are screwed. GError is for recoverable run-time errors, not for installation errors; a missing schema is an installation error. So is a missing ui file, but gtk_ui_manager_add_ui_from_file takes a GError**. by the way, GError, as it is implemented and used currently, is *not* an exception-like system. I'm not against creating a GException, but that's another thing, and the two should not be confused. I don't even see how you could create an exception system in C, short of adding a reference argument to every single function, and rewriting everything to always check and propagate errors after every function call. Not worth it. Just make sure bindings can exercise their exception systems correctly. we don't have g_malloc(size_t, GError**) for OOM cases as well, I just hope you're not honestly asking for that. That would be overkill. And malloc failing is not an installation problem. It's a your-system-can't-handle-this problem. We do have g_try_malloc though, because in some situations, there are actually things you can do. We don't have g_settings_try_new. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Initial work on a help API
On Wed, 2011-05-18 at 11:29 +0200, Rodrigo Moya wrote: On Thu, 2011-04-21 at 16:16 -0400, Shaun McCance wrote: Hi all, I had a project called Squawk I was working on last year. I chatted a bit with Ryan Lortie about it at the recent help hackfest, and decided to work on it again, but this time directly in GLib and GTK+. The basic idea is that GLib has a help provider API that knows about your application's help. It knows more than just that the help exists. It actually knows about all the topics in your help, their URIs, titles, tags, etc. Then there's a set of GTK+ widgets that consume this. If you want to make a help button in a dialog, instead of just making a button and attaching a static URI to it, you'd make a help button and give it a tag. Then it's up to help authors to tag topics for that button. Then do menus the same way. We can kill off the crappy Help-Contents item, and have the Help menu display whatever topics help authors feel are worth promoting to the menu. You can change widget tags at run-time to make them reflect UI state or what the user is doing. I was looking at reducing the number of patches some Ubuntu packages carry over, and one of them (in several packages) is about launchpad-integration, which adds several items to the Help menu (Get Help online, Translate this application and Report a problem), so I was thinking on writing some GtkHelpMenu widget or something similar that does this automatically. Would that be helpful for upstream GTK? I guess it could do what the launchpad integration thing does (pointing to GNOME bugzilla and translations pages, of course, so that Ubuntu would just have to patch that to point to Launchpad) plus what your code does. So, what do GTK maintainers think about it? So a GtkHelpMenu is part of what I'm proposing here, though it's not in the current patch. I've got that code started on my machine. GtkHelpMenu would use the GHelp API, just like GtkHelpButton. My plan for GtkHelpMenu was to have it automatically populated with entries based on tag, exactly like GtkHelpButton, but also show statically-added entries (e.g. Help-About). It would have a search entry at the top. Typing will replace the menu items with any matching topics in the document. So what you're asking for is something in between. It's not the managed topics, because those come from the help file. And it's not the static items, because those are what you have to deal with patching right now. Options: 1) GHelp has a function like g_help_get_static_entries, and you just patch the help provider (or we even provide a way for our help provider to load data, and you install some data files). 2) You just patch GTK+ to insert fixed items between the topics and the statically-added items. In either case, if you don't want to patch applications, then this code has to be able to figure out the correct LP URLs, or if there's even a project in LP for the application. (Think of third-party, possibly proprietary, applications using the API.) With some GApplication work, we could get applications to read something from their .desktop file. Then it could be explicit, e.g. X-Launchpad-ID= You'd still have to patch applications, but with a one-line patch to a data file instead. Thoughts? -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Initial work on a help API
On Wed, 2011-05-18 at 19:12 -0400, Ryan Lortie wrote: On Wed, 2011-05-18 at 09:29 -0400, Shaun McCance wrote: With some GApplication work, we could get applications to read something from their .desktop file. Then it could be explicit, e.g. X-Launchpad-ID= You'd still have to patch applications, but with a one-line patch to a data file instead. I raised the point on the xdg list that I want to add application identifiers (of the org.gnome.Foo sort) to desktop files. Michael Vogt has plans to make this data available in apt (by sucking it out of the desktop files). We could go from application ID to package name (and from there launchpad ID) without the need to patch anything at all. The only concern I have with that is that it assumes that every application on your system is on Launchpad. But if install some commercial application, not from the Ubuntu repositories, it really should not have those Launchpad entries in its help menu. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: migration document missing
On Fri, 2011-02-11 at 10:00 +1100, Andrew Cowie wrote: On Thu, 2011-02-10 at 22:24 +0100, Tadej Borovšak wrote: http://library.gnome.org/devel/gtk3/unstable/gtk-migrating-2-to-3.html Any reason not to have the URLs at .../gtk/3.0/... ? It's there now. It takes library.gnome.org a little while to notice and build documents from new releases. The material under /unstable/ is there from previous 2.9x releases. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: migration document missing
On Fri, 2011-02-11 at 14:03 +1100, Andrew Cowie wrote: On Thu, 2011-02-10 at 19:47 -0500, Shaun McCance wrote: On Fri, 2011-02-11 at 10:00 +1100, Andrew Cowie wrote: On Thu, 2011-02-10 at 22:24 +0100, Tadej Borovšak wrote: http://library.gnome.org/devel/gtk3/unstable/gtk-migrating-2-to-3.html Any reason not to have the URLs at .../gtk/3.0/... ? It's there now. Really? Here we get: http://library.gnome.org/devel/gtk/3.0/gtk-migrating-2-to-3.html http://library.gnome.org/devel/gtk/stable/gtk-migrating-2-to-3.html 404 I just noticed that other /gtk/stable/ URLs point to GTK 2.24; is GTK 3.0 now not the stable release? Regardless, I still don't understand: http://library.gnome.org/devel/gtk/2.24/GtkWindow.html http://library.gnome.org/devel/gtk/3.0/GtkWindow.html What's the parallel filename problem? My fault. I missed that you asked why it's /gtk3/ instead of just /gtk/. I just answered the bit about /unstable/ instead of /3.0/. Because GTK+ 3.x is parallel-installable with 2.x, every file it installs has to be in a different location. That includes its API reference documentation. And library.gnome.org just uses that information when determining where to plop files on the web server. I can see how this could lead some users to get to the wrong place though. Even with navigation and layout that pushes people towards the 3.0 stack, the URLs are so predictable that it's not unreasonable to expect somebody might just type /gtk/stable/ into their location bar. Perhaps we could teach library some tricks with versioned libraries. Frederic Peters would know best. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
On Wed, 2010-11-17 at 16:53 +0100, Max Schwarz wrote: Am Mittwoch, 17. November 2010, um 16:40:16 schrieben Sie: On Wed, Nov 17, 2010 at 10:25 AM, Max Schwarz m...@x-quadraht.de wrote: The problem is not with large deltas (which are thrown away in the current OSX version, if I understand the patch correctly), but with small deltas, which get emitted from Xorg with a pretty high frequency. my initial response to this was sent by completely forgetting what i had done with the original version of the patch. so no, its not true that anything is thrown away. the patch actually adds a new field to scroll events, so that they can have the same semantics as the events on win and quartz. That's correct, but the un-patched port throws away large deltas (there's a break; in there somewhere), and you got around it by storing the deltas in the events. What do you do with small -0.0001/+0.0001 deltas from Xorg? That's the question. If you forward it in GdkEventScroll (and optionally encode that in the proposed delta field), old applications end up getting many GdkEventScroll events, which they interpret as regular scroll events. Result: you scroll a mile when you just move your finger a little bit :-( That's the problem I see. Or is the only receiver of the events GTK itself (GtkRangeco)? Then it would be possible to patch it all at once... Most application code probably doesn't use GdkEventScroll directly. It's handled inside GTK+ for things like scrolled windows. But some applications and some libraries might use GdkEventScroll for something clever. I know vte uses it to let your scroll wheel work in programs like less. If we break API on this, I think it would be best to do it in a way that the compiler catches it. Just adding a field to GdkEventScroll will trip up a lot of developers. -- Shaun McCance http://syllogist.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Sun, 2010-08-29 at 19:02 -0400, Havoc Pennington wrote: Hi, Matthias's mention of padding props got me thinking about how this could be mopped up (based shamelessly on what we did in HippoCanvas and then BigBox) I'm attaching a patch that I haven't even tried to compile (my jhbuild setup is kinda hosed, don't ask) illustrating what I might like to see if starting from scratch. In brief it adds to GtkWidget: h-align, v-align = FILL, CENTER, START, END padding-left,padding-right,padding-top, padding-bottom = int16 Would it be better to have padding-start and padding-end, rather than -left and -right, and have it do the right thing in RTL locales? I've often wished CSS did it that way, and GTK+ does do most things with start and end already. -- Shaun McCance http://syllogist.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Scrollable interface for 3.0?
http://library.gnome.org/devel/gtk/stable/GtkScrolledWindow.html#ftn.id1043260 The scrolled window installs GtkAdjustment objects in the child window's slots using the set_scroll_adjustments_signal, found in GtkWidgetClass. (Conceptually, these widgets implement a Scrollable interface; because GTK+ 1.2 lacked interface support in the object system, this interface is hackily implemented as a signal in GtkWidgetClass. The GTK+ 2.0 object system would allow a clean implementation, but it wasn't worth breaking the API.) Is this worth breaking API for in 3.0? -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
On Wed, 2010-05-12 at 09:29 +0200, Cody Russell wrote: 2/ Corner resize grips. I want to add support for this directly to GtkWindow anyway. Is anybody actively working on this? Are there ways of doing this that don't a) require vertical padding a'la GtkStatusBar, or b) unilaterally cover up whatever is in the bottom right corner? A lot of document-viewing applications have a GtkScrolledWindow that hit the bottom right. If both the vertical and horizontal scrollbars are visible, there's some really nice dead space there. But if only the vertical is visible (very common), you certainly don't want to cover up the scroll-down button. Could GtkScrolledWindow know that there's a resize grip there and do something like this: +--+ |^ | || | || | || | || | |v | |//| +--+ I suppose we could add API like always_show_blank_corner, but it would be really nice if it were automatic. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook scrolling usability
On Wed, 2010-03-10 at 17:25 -0600, Jason D. Clinton wrote: On Wed, Mar 10, 2010 at 4:50 PM, Cody Russell brats...@gnome.org wrote: He suggested that maybe there's a use for it in the case that you have a ton of notebook tabs open, but I'm not quite convinced. Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) I don't recall where but I'm fairly sure I saw someone using that to flip through open tabs in Epiphany. You might have been watching me. I do it all the time. But I don't think I ever do it in preference dialogs or other places where there's a static set of tabs. I'm sure there are people who trigger this accidentally, and it's very annoying for them. And I'm sure there are people who love this feature. So, you know, trade-off. -- Shaun McCance http://syllogist.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GConverter commited
On Tue, 2009-11-24 at 09:36 +0100, Alexander Larsson wrote: On Mon, 2009-11-23 at 21:57 -0600, Shaun McCance wrote: I'll be using the bzip2 and lzma converters in Yelp. I'm not sure about the magic converter. I might just throw it away and go off the file name. The magic detection is not suitable for general use, though I think it's OKish for Yelp. Although this Debian bug report concerns me: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364260 lzma is detected by shared-mime-info (i.e GContentType), but only if it has the right extension. Extending the database with magic info shouldn't be that hard though. Right, so I looked at both shared-mime-info and file when I was putting together the magic. The bytes I used came from file, but they're commented out, because of the bug I linked to. See comment #62. Coincidentally, I *just* received a bug report to support the new xv in Yelp, which is replacing lzma. I assume the new format produced by this will be the one mentioned in that bug, which does have a sniffable signature. Also, when putting together chains of streams when content may or may not be encoded, I think it would be useful to have some sort of NullConverter, i.e. a GConverter that doesn't change anything. Would anybody else find that useful? I'm not sure why you'd need this, you just don't add a GConverterInputStream in that case. Well, the way I did the magic was with a GConverter that inspects its data the first time convert is called, and then constructs another GConverter to pass everything off to. (This assumes the first call to convert has at least some number of bytes, by the way.) So with my implementation, by the time you get to the magic, you've already set up a GConverterInputStream with the magic decompressor. If the stream turns out to be uncompressed, you'd have to do a null conversion. I suppose the magic decompressor could just have the null conversion built in. Anyway, since I was one of the people wanting this, I thought I'd share my first experiences with it. I'm curious what other people would like to do about GConverters for other compression schemes. The code is simple enough that I don't really mind keeping it in Yelp. But if other people are doing this stuff, maybe we should talk about how to share code. Yeah, sharing things like this is good, but we don't want every app to link to these libraries, and even gio plugins are not free (even when not used) since we load them once to see what extension points they support. Its not a lot of code either, nor is it very complicated, so maybe cut and paste is not such a horrible idea. I don't disagree. Is there a place to plop this code for people to pick it up? I'll be putting at least the bz2 and lzma converters into Yelp soon (or possibly an xv converter instead of the lzmadec-based one). I'm still undecided on the magic converter. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GConverter commited
On Tue, 2009-11-24 at 16:22 +, Bastien Nocera wrote: On Tue, 2009-11-24 at 10:09 -0600, Shaun McCance wrote: snip I don't disagree. Is there a place to plop this code for people to pick it up? I'll be putting at least the bz2 and lzma converters into Yelp soon (or possibly an xv converter instead of the lzmadec-based one). I'm still undecided on the magic converter. I've written some code for gdk-pixbuf's XCF loader to use GConverter to uncompress gz files, and would be happy to clean up the code to use the same codepath for bz2. So I'd be happy to see your code. Code is here: http://www.gnome.org/~shaunm/git/convert.git The bz2 converter was pretty trivial to write. The one possible hiccup is the implementation of reset. Since libbz2 doesn't provide a reset function, I just ended and reinitialized the stream. But I didn't actually test it. GConverterInputStream doesn't actually call reset. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GConverter commited
On Tue, 2009-11-24 at 17:20 -0500, Behdad Esfahbod wrote: On 11/24/2009 11:09 AM, Shaun McCance wrote: So with my implementation, by the time you get to the magic, you've already set up a GConverterInputStream with the magic decompressor. If the stream turns out to be uncompressed, you'd have to do a null conversion. I suppose the magic decompressor could just have the null conversion built in. Isn't it like a matter of memcpy() in convert(), and nothing in reset()? Not that I oppose a cat-converter. Oh duh. I was thinking it was slightly less trivial, that you'd have to maintain a buffer in case outbuf is smaller than inbuf. But I just realized that convert doesn't have to consume all of inbuf. That's what bytes_read is for. So I updated my magic decompressor in my git repository so that, if it doesn't detect any compression, it just passes the data through. It's like six lines of code. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GConverter commited
On Mon, 2009-11-23 at 16:30 +0100, Alexander Larsson wrote: I just commited GConverter to glib master (in gio). GConverter is a generic interface for streaming data conversion. Shipping with gio are converters based on iconv and zlib compression/decompression. Additionally there is GConverterInputStream and GConverterOutputStream for doing the conversion automatically as part of reading or writing a file. At the moment the compression support is just zlib, but theoretically it should be possible to make decompression a generic extensible thing so that extensions can ship other compression algorightms that are picked based on file sniffing. I'm not 100% sure this is all that useful though. And for compression its not quite possible since the exact parameters used for compressions vary for different compression algorithms. Please check out this API and give comments on it. I think its pretty good, as we've talked about this a bit on irc over the years, but feedback is always good. Thanks. I threw together some decompressors for bzip2 and lzma. I also cobbled together a quick magic decompressor that inspects the first two bytes to determine what to do. Code is here: http://www.gnome.org/~shaunm/git/convert.git I'll be using the bzip2 and lzma converters in Yelp. I'm not sure about the magic converter. I might just throw it away and go off the file name. The magic detection is not suitable for general use, though I think it's OKish for Yelp. Although this Debian bug report concerns me: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364260 Also, when putting together chains of streams when content may or may not be encoded, I think it would be useful to have some sort of NullConverter, i.e. a GConverter that doesn't change anything. Would anybody else find that useful? Anyway, since I was one of the people wanting this, I thought I'd share my first experiences with it. I'm curious what other people would like to do about GConverters for other compression schemes. The code is simple enough that I don't really mind keeping it in Yelp. But if other people are doing this stuff, maybe we should talk about how to share code. Thanks again, Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:17 +0100, Alexander Larsson wrote: On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. The API in question includes compression and decompression as streams (among other things), and is pluggable. Code to do automatic detection of compression type could easily be added. However, having some level of support being guaranteed (i.e. a mandatory dependency) has additional value that something being pluggable doesn't. For instance you could distribute zlib compressed data (as file or linked into your app) and depend on all glib installations being able to decompress that data. It also means you can e.g. design file formats based on a specific compression algorithm and never run into issues with some platform not having what is needed to read the file. Plugin-based optional compression support is basically only useful for best-effort decompression of unimportant document files. Thats obviously nice to have, but not as important as reliable compression support. That sounds fair. Right now, Yelp will happily build without bzip2 and lzma support if you don't have them. I consider it a distro problem: if distros want to ship man and info pages compressed with bzip2 or lzma, then they need to make sure their Yelp is built right. I have no problems pushing that policy decision lower. How do you envision the optional extra support being provided? Would there be extension points that GVFS could plug into? Or compile-time optional modules like the GdkPixbuf loaders? Or would applications be expected to provide the extra juice? I'm willing to do the grunt work to add these. It's work I'd have to do in Yelp anyway to fully transition to GIO. Thanks for tackling the hard part of the problem. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. GIMP currently has bad hacks to support transparent loading of .xcf.gz and .xcf.bz2 files and it would be nice to let this be handled at a lower level. Yelp has a custom GIOChannel for transparent loading of gzip-, bzip2-, and lzma-compressed man and info files. I'd also be very interested in a GInputStream that handles this for me. There was a thread about this in July: http://mail.gnome.org/archives/gtk-devel-list/2009-July/msg00133.html Alex, I'm not sure what your plan is, but if you're planning some sort of GFilterInputStream to do automatic decompression, I think making it zlib-only would miss the mark for what most people would want to use it for. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Has anyone been able to force TreeView expander with no children?
On Wed, 2009-10-14 at 18:52 -0700, Daniel B. Thurman wrote:
I have a FileViewer application that I am working on
and so far I have not been able to force expanders
on TreeView when there are only top-level
directories/files populated in the TreeStore.
You would think that doing something simple as:
[...]
self.treestore = gtk.TreeStore(str, gtk.gdk.Pixbuf, str)
self.treeview = gtk.TreeView(self.treestore)
self.treeview.set_show_expanders(True)
self.path = os.path.expanduser('~')
self.populate_treestore(path=self.path, recurse=0)
[...]
Would force the TreeView to show the expanders,
but I have not been able to get this to work. I need
the expanders so that when I expand the directory
in question, I would then trigger a call to add more
children, and so on.
If you want to populate data on-demand like this,
you're probably going to have to write your own
GtkTreeModel.
--
Shaun
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GZip{In,Out}putStream in GIO?
On Sat, 2009-08-15 at 10:07 -0400, Morten Welinder wrote: FWIW, Sugar uses zip quite extensively to bundle content and software and we would love to move from using python's zipfile to something glib-based. Why all this reinvent-the-wheel effort? libgsf gives you access to zipfiles and is glib based right now. Does libgsf use the GIO APIs? Ideally, people should just be able to write their programs to expect a GInputStream. And then if some other library happens to be providing a FooRot13InputStream, it doesn't matter. I understand that libgsf predates GIO considerably. For my purposes, if I needed to deal with complicated structured files, I'd certainly look to libgsf. But all I need to do is decompress a file and read it. Right now, it took all of 231 lines of C to do it in Yelp, and most of that is boilerplate. It's just not worth an extra dependency for me. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
2009/7/31 Brian J. Tarriconebj...@cornell.edu:
On 07/31/2009 05:48 AM, Mikkel Kamstrup Erlandsen wrote:
From the looks of it, it should be straight forward to write
GZip{In,Out}putStream classes based on zlib
I'd say call it GCompressed{In,Out}putStream and have it either auto-detect
the compression type, or have a param in the API to specify from an enum
(or
both). People can add support for other types of compression as time goes
on.
It's nice to see I'm not the only person that's after this.
I'm not sure what other people need this for, but I thought
I'd give a data point for why it's useful to me.
Yelp currently has its own subclass of GIOChannel that does
decompression on the fly for gzip, bzip2, and lzma.
http://git.gnome.org/cgit/yelp/tree/src/yelp-io-channel.c
It's not a particularly elegant solution. It has everything
in one file, with bzip2 and lzma functionality in #ifdefs,
and determines what to do by file extension. But it does the
job for Yelp, which needs to read man and info pages that may
be compressed.
(It's also a fairly trivial and not-complete implementation.
For instance, it doesn't do seeking, because Yelp doesn't
need it.)
I've been looking at converting Yelp over to GIO, so having
such an InputStream would be very useful to me. If it's not
in GLib, I'll have to do my own.
I'd really need all three of the above compression schemes to
work. If a gzip-only InputStream is done, I can always ship
my own bzip2 and lzma implementations.
A flexible system using runtime-loadable backends is fine for me,
as long as I know bzip2 and lzma implementations are available.
I don't particularly care about having a guarantee that they're
there. Distributions that ship lzma-compressed man pages can
just make sure the backend is installed. Not my problem.
And yes, this is me volunteering to do the work, but not until
I get around to gutting Yelp, which will be in maybe two months.
I'll have to do the work anyway for Yelp. It would be nice to
get input from the maintainers about what approach they think
is best.
--
Shaun
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Suggested even/odd convention for the micro version numbers (like cairo)
On Tue, 2007-12-11 at 10:37 +0200, Tor Lillqvist wrote: I humbly suggest that the versioning recommendation for the GTK+ stack and GNOME in general is amended for the third micro part of the version numbers to match the convention used in cairo. See http://cairographics.org/manual/cairo-Version-Information.html . In a nutshell, the idea is that released tarballs have an even micro version. The micro version is bumped both immediately before and after building the release tarball. The even micro number is never committed to SVN. In SVN the micro number is always odd. So making the 2.12.2 release would look like this? 1) Change the version from 2.12.1 to 2.12.2 in configure.ac 2) Edit the NEWS file 3) make distcheck 4) Change the version from 2.12.2 to 2.12.3 in configure.ac 5) svn commit Whereas it currently looks like this: a) Change the version from 2.12.1 to 2.12.2 in configure.ac, unless you did a pre-release bump already b) Edit the NEWS file c) make distcheck d) svn commit e) svn cp $(url)/trunk $(url)/tags/MY_PROGRAM_2_12_2 The problem I see with the proposed scheme is that we can't fit step (e) into it, since 2.12.2 is never in SVN. With our current scheme, you can do this: svn checkout $(url)/tags/MY_PROGRAM_2_12_2 make distcheck and get, in theory, exactly the tarball that's sitting on ftp.gnome.org. If 2.12.2 is never in SVN, that's not going to be possible. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_show_help and gtk_show_url
On Thu, 2007-10-25 at 17:36 -0700, Matthew Paul Thomas wrote: Sorry to come in here wildly late, but ... On Oct 8, 2007, at 8:34 AM, Shaun McCance wrote: - What sort of information does the Mac help system need? ... http://urlx.org/apple.com/d50c3 Help buttons in Mac OS X (in bundled software, at least) usually don't open exact pages. Instead they open search results, in which the actual page the developer was thinking of is the first or second result. This is, I assume, because Apple are afraid of the software and the help getting out of sync. If a Help button linked directly to a page that had been renamed, or merged into another page, the help viewer would have to return a nasty error The help topic does not exist, contact your application vendor for an updated Help file à la Windows, and people would be put off trying to using the help ever again. I think that's a valid concern, but an annoying solution. I would rather that any updated API for opening a help page in Gnome had two compulsory parameters -- one for the page ID, and one for a fallback search string if Yelp can't find the page. That way the page-not-found error would only ever appear when debugging. This is an interesting idea. But it leaves me with a few questions. * Under what circumstances would the application and the help files ever become out of sync? We release them in the same package, so they should (in theory) always be in sync with each other. Note that: - gnome-doc-utils contains a little-used utility that generates a header file with symbols for each page. If you use these instead of raw strings, you avoid typos or other problems with page IDs. They would cause a compiler error. - Both DocBook and Mallard provide a means of putting additional anchors on things. So when you do some sort of surgery on your document, you really ought to put an auxiliary ID somewhere so that links don't break. - In practice, I realize it's common for the help files not to keep up with the application. But this is not the sort of thing that causes broken IDs. Also, search strings wouldn't help much, because in these cases, the content just isn't there. * A search string really should be translated if it's pointing to translated help. But if it's pointing to English help, it shouldn't be translated, even if the application is translated. Currently, our application translations are much more complete than our document translations. So I'd be worried that this would cause a different sort of out-of-syncness: a German search string getting used on an English document. * In my experience, when you have compulsory parameters that don't usually do anything, most people will just do what they need to shut up the compiler. So instead of this: gtk_help_show (user-guide, printer-configure, anchor, configure printer); They'll do this: gtk_help_show (user-guide, printer-configure, anchor, ); Alternately, they might write very unhelpful help strings, because they're in a hurry to write real code, and don't want to think about help stuff. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_show_help and gtk_show_url
On Sun, 2007-10-07 at 17:10 -0400, Havoc Pennington wrote: Hi, Sketching out an API here, prototype attached. See also http://mail.gnome.org/archives/gtk-devel-list/2007-September/msg00139.html Some questions: - in current GNOME, what are the right parameters to open a help file? (i.e. what values does gtk_help_show() need to open a gnome help file, such as document ID or anchor or whatever) http://library.gnome.org/devel/libgnome/stable/libgnome-gnome-help.html#gnome-help-display The most common way to open a help file is to pass a document ID and an anchor ID. DocBook documents are automatically paginated, and Yelp turns the anchor ID into a [page ID, anchor ID] pair. It loads the page and jumps to the anchor. The _with_doc_id variant is rarely used at this time. It effectively allows you to specify which file to load in a document's directory. Since DocBook documents are a single file, and we don't put multiple documents in one directory, it's not useful. However, a three-identifier variant is useful for document types that are already split into pages. This includes collections of HTML files and (real soon now) Mallard documents. So basically, if GTK+ can pass Yelp (through whatever means) a triplet of identifiers, we can make magic happen. Some questions: - What sort of information does the Windows help system need? - What sort of information does the Mac help system need? - What about other GTK+-using desktops, like XFCE and Rox? -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
