Re: migrating gtk
ing to attach a patch. Or reply "this bug still exists" without > > testing it, because you're too busy with your own stuff. > > > > Ciao, > > Emmanuele. > > > >> On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <eba...@gmail.com> > wrote: > >>> On 4 February 2018 at 20:52, Morten Welinder <mort...@gnome.org> > wrote: > >>>> As a general principle, you should only ask bug reporters to do work > if you > >>>> intend to do something with the answer. Or, with other words, it > really is > >>>> not nice to keep asking "is that bug still there?" until they get > tired of the > >>>> busywork and leave in disgust. > >>> > >>> The busywork meaning "attaching a patch and iterating over it"? > >>> Considering that you usually stop short of the first step I have to > >>> ask you: what kind of "busywork" have you ever experienced? > >>> > >>> Of course if we get a positive response that the bug is still there > >>> we're going to migrate it and keep track of it. > >>> > >>>> With that in mind, I believe it is much nicer to just leave the old > bugs there. > >>> > >>> The old bugs will be left there, but closed, so we don't need to check > >>> two bug lists, and split the maintenance resources even more. > >>> > >>>> We never got around to solving the reporter's problem, but at least > we did > >>>> not add to the pain by asking them to do work and report back, only to > >>>> ignore the result of that. Doing that is quite rude. > >>> > >>> Of course it is, that's why we generally don't do that — except, > >>> maybe, for rude bug reporters. > >>> > >>> Ciao, > >>> Emmanuele. > > > > > > > > -- > > https://www.bassi.io > > [@] ebassi [@gmail.com] > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving to glade and GtkInspector
Hey Martin, When I maintained gnome-calculator I ported a bunch of Widgets to use GtkBuilder templates: https://blogs.gnome.org/tvb/2013/04/09/announcing-composite-widget-templates/ This allowed me to massively reduce my codebase as I turned the UI into content, I also used the chance to port many layouts from nested v/hboxes to the newer GtkGrid. GtkBuilder templates are generally encouraged and we even do so in Gtk+ itself. While glade is not perfect, moving my handcrafted UI code to .ui files certainly made my life easier as a maintainer. 2017-04-03 6:29 GMT+01:00 Martin Owens <docto...@gmail.com>: > Hi Gtk Devs, > > I'm brining this up in devel mailing list because it might not be > possible to do well enough, but I'm interested in raising the question > of moving projects from widget code to glade ui files. > > I work on Inkscape. The next version of Inkscape (0.93) will be Gtk3 > and Gtk2 is now removed from our codebase. But we're still generating > all of our widget trees in-code and is kinda hurts redesigning our > dialogs. > > Is it worth moving to glade for parts of a large gtk3 app, does it help > with css adjustments at all and would it be an acceptable patch to make > the gtkinspector dump out our existing widget trees (it would be really > nice to have it generate glade xml, but that's just silly right). At > least getting the data out of the inspector and into a python script > for generating the xml would be a start. > > Any ideas, or thoughts? > > Thanks for your help, Best Regards, Martin Owens > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
HELP: fixing nullable annotations for return values
Hello Gtk hackers, During GUADEC I decided to revive a small effort I took a while ago. I wrote a script using the private GObject Introspection AST API to check if %NULL was mentioned in the documentation string of any return value in any way that indicated that such function/method was likely to miss the (nullable) introspection annotation. I came up with a list of 143 functions that I'm trying to fix on a branch (wip/aruiz/nullable-annotations), the plan is to collect and review all the fixes there and then rebase/sqash into master eventually. I'm tracking the effort on bgo#753520 [0] and using this Google Spreadsheet[1]. Anyone interested in helping fixing any of the listed functions, just add your IRC nickname in the owner list in the spreadsheet[1] and push into that branch. I only ask of a few things before pushing: - Check if (transfer none/full) applies - Rename NULL or #NULL as %NULL if you have the chance. - Check if the function is actually nullable, my script may be mislead by whatever is in the document. If we have any clang hacker, it'll be great if we could tool this into the compiler to check at compile time if a given function can return NULL at some point. To have something like this integrated in Builder and gobject introspection would certainly prevent new APIs to suffer from this problem. Any further feedback or help with this effort in other libraries would be greatly appreciated. [0] https://bugzilla.gnome.org/show_bug.cgi?id=753520 [1] https://docs.google.com/spreadsheets/d/1okGq07H4NnOqdCRN0KV3QduOQ6zsiomFmqK0pqYNNpo/edit#gid=141782806 -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
I don't see much of a debate there. Most people want to solve a problem, and start from the problem, not from the tool to solve it, it's not like home improvers go hey there's this really nice drilling machine, I should buy some shelves to learn how to use it. People who are likely to use GTK will start from the problem they want to solve and are in need for a graphical toolkit to draw widgets that do what they want. Quite frankly advertising C/GObject as the reference language for newcomers is something we already agreed was not recommended during the UX hackfest and that's why we decided to choose JavaScript as the entry point. Point them at what the toolkit does and the easiest way to use it, and people will learn as they go. GObject and GIO by themselves are of no interest for most people wanting to write apps, specially in C. 2015-01-23 18:05 GMT+00:00 Sébastien Wilmet swil...@gnome.org: On Fri, Jan 23, 2015 at 09:27:37AM -0800, Jasper St. Pierre wrote: The learning path for writing a GTK+ application should be: GLib - GObject (at least the basis) - a bit of GIO - and finally GTK+. All GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's important to explain what it is, at least briefly. I disagree. The learning path for writing a GTK+ app should start with GTK+ and let them venture into the utility libraries of GLib and Gio when they need to. No need to start with here's the library that seemingly reinvents all of C99 because people sometimes still use SunCC in TYOOL 2015. It's all the debate between the bottom-up and top-down approaches. Maybe a good compromise is a mix between the two, because it's more fun to show a window with three buttons than learning how to create a signal. But sooner or later a developer needs to know GLib and GObject. For a potential book about GTK+, there can be a short chapter on GLib to learn the basis, then an introduction to GTK+ with some basic explanations on how to _use_ a GObject class, then a chapter to know how to _write_ GObject classes. For what it's worth it was roughly the path chosen in GGAD. Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
Hi Sebastien, First of all thanks a lot for working on this! However, for a brochure about a graphical toolkit, I find it interesting that there are no GTK+ apps' screenshots. Perhaps I would suggest something less verbose and more to the point with captures of GNOME 3 apps'. 2015-01-22 21:01 GMT+00:00 Sébastien Wilmet swil...@gnome.org: Hi, Just a quick note to announce that I've written a brochure about GLib/GTK+: https://github.com/swilmet/gtk-brochure https://people.gnome.org/~swilmet/gtk-brochure.pdf Nothing revolutionary here, some chunks of text come from the gtk.org website or from the API references [1]. But for a technical conference like FOSDEM it was something missing. I've already posted this on the engagement-list, where there has been some reviews (thanks!). So if you have other comments, don't hesitate! If everything goes well, the flyer will be available on the GNOME stand this year at FOSDEM. Of course I hope the document will be useful for other technical conferences. Cheers, Sébastien [1] For a small text like this, copyright and license information shouldn't be a problem IMHO, normally the people who have written the original text on gtk.org or the API references implicitly agree that the text is sometimes copied (it's for the own good of GTK+). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
I agree with Paul here, GTK+ targets people who want to do desktop apps. I would actually try to sell all the new stuff for developers like the new introspection tool, the new widgets and some of the new CSS work with snippets. 2015-01-22 22:34 GMT+00:00 Paul Davis p...@linuxaudiosystems.com: On Thu, Jan 22, 2015 at 5:20 PM, Sébastien Wilmet swil...@gnome.org wrote: On Thu, Jan 22, 2015 at 09:33:18PM +, Alberto Ruiz wrote: First of all thanks a lot for working on this! However, for a brochure about a graphical toolkit, I find it interesting that there are no GTK+ apps' screenshots. Perhaps I would suggest something less verbose and more to the point with captures of GNOME 3 apps'. My gut feeling is that most people of the target audience already know what a GTK+ app looks like. But having at least one screenshot would be nice, indeed. I can try to shorten the GObject section so a screenshot can be added in the GTK+ section. For app developers, GObject is probably the least interesting part of GTK. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
My main concern with the design is that users can't make a difference between a normal button and this widget (usually related to an action, perhaps with the exception of iconized menus like the ones we're using in headerbars these days). Is there any design rationale to remove the usual arrow? 2014-12-27 13:02 GMT+00:00 Matthias Clasen matthias.cla...@gmail.com: Hi, over Christmas, I had some for a little side project, a new combo box. It is based on these mockups: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png One question I need some feedback on is naming: We currently have GtkComboBox and GtkComboBoxText. I've gone with GtkCombo for now, which has the downside that there is a widget by that name in gtk2. Alternatives might be GtkChoice or GtkComboButton (with a possible avenue for making the list-of-choices available for direct embeeding as GtkComboWidget later). There are some lose ends in the code, like the interaction of grouping and search, but it is complete enough to give it a try and evaluate the design. If you want to try it, the code is in the wip/combo branch, and there is a testnewcombo test app with some examples. I'm off for a few days now - would be great to hear some feedback when I come back. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A Gtk's build system ?
Waf is actually pretty good at building stuff for non-Linux platforms (for example, it transparently supports MSVC without the need of VS project files). I'd bet that it may have some issues building for Linux on non popular architectures or weird/old UNIX flavors as it doesn't do the sort of comprehensive checks that autoconf does by default. Beyond that, the fact that is python based does make the build system more portable across systems, it is certainly more portable than the mashup of bash and unix command line tools that autotools sipts out. Waf is being used by Samba last time I checked and I am pretty sure they have a wide range of platform and OSes to target so it surely isn't that bad. However, building Gtk+ is not trivial and I am sure waf is going to require some fixing before it can support a full build, if people want to take on the task of setting up a branch and checking what it would look like, I would be happy to help upstreaming any extensions needed (I have commit rights in the waf repository). On the other hand I wouldn't keep my hopes too high that the Gtk+ maintainers are going to happily move over unless someone shows what major improvements the port would bring. 2014-08-06 22:35 GMT+02:00 Christian Hergert christ...@hergert.me: Sounds like we have some people willing to port the build system to waf! But seriously, without seeing what it would look like on another system, this thread can't go much further. Autotools is what it is, and Gtk+ is one of the most portable pieces of software in our ecosystem. Making sure that waf runs properly on all of the target systems is going to take some upfront work. Just because it uses Python doesn't mean it's portable. Plenty of Python API's return different values based on the host operating system. -- Christian On 08/06/2014 01:01 PM, Krzysztof Kosiński wrote: 2014-08-06 21:43 GMT+02:00 Colomban Wendling lists@herbesfolles.org : Le 06/08/2014 21:30, Krzysztof Kosiński a écrit : [Waf] does not require silly lists of files to work If that refers to using globs in the build system files, don't. Glob showed on many a situation to be the source of various build problems, including, but not limited to, a file to be missing from the source tree (which would not be easily noticeable and would work on the author's setup), or unexpected files to be included in a build. I am not really convinced by this. 1. If there are any uncommitted files, version control will tell you about this. 2. If you have 'unexpected files' in the source tree, you are doing something wrong. 3. Another common argument in favor of file lists is determining what to include in the tarball. This is only an issue because by default Autotools create a giant mess by putting generated files in the same directories as the sources (CMake does this as well). Waf always puts all generated files in a separate directory, so everything that's not in the build directory should be distributed. Also, FWIW patterns can generally be used just fine in Autotools -- but again, please, don't use them. Autotools can't correctly use patterns / wildcards, because it requires manually re-running automake whenever a file is added or deleted. http://www.gnu.org/software/automake/manual/html_node/Wildcards.html Waf stores a database of files seen on last build and therefore doesn't suffer from this problem. Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: dynamically load an UI in a main UI
Perhaps you should use WebkitGtk+ and distribute that part of the UI as HTML/JS? :-) 2014-04-30 0:09 GMT+02:00 narcisse doudieu siewe wambenarci...@yahoo.fr: Hello, Just a question...suppose that you have some clients and each client has a main application UI(user interface) which is just a GtkWindow instance and suppose that for some business reasons, you have to create at need a child UI (which subclass any GtkContainer like GtkBox or GtkGrid for example) you actually make you UI, compile the code of this UI and after you distribute it over internet to your client. This client has to get the code, load this code which becomes the child UI of the main UI...what can I do that? I have take a look at GTypeModule but I cannot find any example and particularly where the code should stay(in the client's machine) to be loaded properly thank. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Removal of icons in buttons/menus
The sole fact that we are having a discussion in these terms is a bit shameful, I think no one in this list has the right to say Gtk+ is the GIMP or the GNOME toolkit. Gtk+ is _a_ toolkit with many contributors that contribute for various reasons, all of those are valid, and sometimes compromises have to be made. Most of the contributors are GNOME developers and very few if none of the core/active developers runs Windows or Mac OS X or other DEs on a daily basis have pushed Gtk+ to be a toolkit mostly targeted to the Linux desktop and more specifically towards GNOME. Aligning the resources that we have to make Gtk+ a great toolkit for GNOME is a worthwhile effort, and I am certainly glad that we are ready to sacrifice certain cross-platformness for the sake of shining in Linux and GNOME. Trying to be everything to everyone, specially when we have scarce resources is a disaster and the cause for Gtk+ to be stagnant for longer than it should. Besides all of this, the particular change in question affects app users and application developers of non GNOME environments for very little gain in our side (Ryan already raised up this point in a previous email), did we really need to start ignoring this XSetting before 4.0? I haven't seen a compelling answer to this question yet other than if it's not running in GNOME we don't care, maybe the application writers do care...? 2013/10/9 Andrew W. Nosenko andrew.w.nose...@gmail.com: On Wed, Oct 9, 2013 at 11:55 PM, Bastien Nocera had...@hadess.net wrote: On Wed, 2013-10-09 at 22:45 +0200, Michael Natterer wrote: On 10/09/2013 10:40 PM, Bastien Nocera wrote: On Wed, 2013-10-09 at 22:14 +0200, Olivier Brunel wrote: Ok, but this isn't about a change in GNOME, but in GTK. And the default for those options was still TRUE a few days ago in GTK 3.8 As we're on this subject, I think it's pretty clear, from the committers to where the mailing-lists are hosted that GTK+ is the GNOME toolkit. People deeply involved in other desktops that rely on GTK+ should try to get more involved in decisions made for the GNOME toolkit. Oh please, not this silly GNOME Toolkit stuff again. GIMP runs on windows and osx, so do many other applications. So please... They're GTK+ apps running on Windows and OS X, not Windows apps, or OSX apps. Bastien, excuse me, but Michael's reference to The GIMP was a hint that GTK (with or without '+' -- no matter), stands for The GIMP Toolkit. GIMP, not GNOME. Proof: http://www.gtk.org/ -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Github mirror script broken
That is my bad, it should be fixed now :-) 2013/8/13 John Ralls jra...@ceridwen.us: I've gotten the following error on my last couple of pushes -- and they don't seem to have gone through to Github: remote: Traceback (most recent call last): remote: File /home/admin/bin/git/post-receive-mirror-github, line 161, in module remote: raise e remote: Exception: Gtk+ has a '+' character in it which is unsupported by Github. remote: You have to add it to the exception maps in the post-update hook. Did somebody mess with the post receive hook? The mirrored repo on Github is called gtk for just this reason. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [RFC] Fixes in GtkFontChooserWidget
I've gone ahead and applied the scrolling fixes with ebassi's blessing I will wait for some feedback from designers wrt the GtkScale value being shown. 2013/7/20 Alberto Ruiz ar...@gnome.org: Hello, I have created a branch[0] with a few minor changes to GtkFontChooserWidget One of the commits is a fix to solve a problem with smooth scrolling in the slider. The other one removes the value from the slider which is redundant (and innacurate at times) wrt the value in the spinbutton. I wrote this widget originally so I'm mostly certain I know what I am doing but since I am doing UI changes I wanted to get someone reviewing the code before pushing. PS: [0] https://git.gnome.org/browse/gtk+/log/?h=wip/fontchooser-fixes -- Cheers, Alberto Ruiz -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[RFC] Fixes in GtkFontChooserWidget
Hello, I have created a branch[0] with a few minor changes to GtkFontChooserWidget One of the commits is a fix to solve a problem with smooth scrolling in the slider. The other one removes the value from the slider which is redundant (and innacurate at times) wrt the value in the spinbutton. I wrote this widget originally so I'm mostly certain I know what I am doing but since I am doing UI changes I wanted to get someone reviewing the code before pushing. PS: [0] https://git.gnome.org/browse/gtk+/log/?h=wip/fontchooser-fixes -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Agenda for the GTK team meeting of November 29th, 2012
Kudos to Emmanuele for taking care of this! 2012/11/26 Emmanuele Bassi eba...@gmail.com hi all; • Upcoming Meeting - Date: Thursday, November 29th, 2012 - When: 20:00 UTC - Where: #gtk-devel on irc.gnome.org • Agenda: - Notifications (cosimoc), Bug 688492 - Scrollbar markers (aruiz), Bug 623712 - Frame synchronization - Discussed on the mailing list - Using $HOME in g_get_home_dir() - Guidelines for stable branches of GLib and GTK+ - GProperty status - Add template and object exporting to GtkBuilder - Mainloop debuggin - Sharing settings between GtkFileChooser and Nautilus - Miscellaneous • Wiki: https://live.gnome.org/GTK+/Meetings ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Scrollbar markers
Hi, I have recently updated my scrollbar markers branch in github and pinged people subscribed to #623712 This new approach adds a signal during draw so that the know what the geometry of the through and the slider is, and also to be able to draw markers before the trough is drawn. I would like some input from people more familiar with the new theming infrastructure and make sure I'm not doing anything crazy or wrong. You can compare the changes against master here[1] [0] https://bugzilla.gnome.org/show_bug.cgi?id=623712 [1] https://github.com/aruiz/gtk/compare/master...wip;scrollbar-markers -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: path= (or not) in GSettings schemas
On the more extremist side of my point of view: https://lkml.org/lkml/2012/3/8/495 }:-) From a more reasonable standpoint, expecting app developers to keep up with every single library's changes is bad, specially for something so fundamental as GLib/GIO. I do think it's unfortunate, but I think that fixing this by breaking compatibility is creating a whole new problem. I'd go for adding path=id and making a better job at documenting this. I do like the idea of adding relocatable=yes, we could add an informative warning to get people to start using it if just id is provided, that should help to migrate in the future, but I won't change it as long as GSettings is on a stable series. Another idea would be to care less about the usability of the XML format and create an embeddable GUI to create schemas that people could use standalone or integrated with Anjuta/Monodevelop/FooBarIDE, having humans writting XMLs is a bad idea anyhow. 2012/10/17 Ryan Lortie de...@desrt.ca hi, One of the big design mistakes I made with GSettings is that this is really weird: schema id=org.a11y.atspi path=/org/a11y/atspi/ The requirement to specify a separate path is confusing. It causes people to think that maybe the path should have a prefix like /apps/. If you manage to avoid this trap and do it properly then it is completely redundant. Of course, it is possible to omit the path to create a relocatable schema. schema id=org.a11y.atspi That's the crux of the mistake. Relocatable schemas are somewhat rare in their use. The non-relocatable case is the 'ordinary one'. Ideally, the syntax (immediately) above should have been reserved to that common case. Changing this now is a no-go, of course. There are existing applications that use the above syntax to define relocatable schemas. I propose that we could bail ourselves out of this mess with a two-step process, as follows: 1) Start looking for a relocatable='' attribute on schema. If a schema has no path and has not been marked as relocatable='yes' then emit a warning (similar to what we do for path='/apps/*' already). 2) After a year or so, assume that schemas without relocatable='yes' and with no path='' are schemas that wish to have a path automatically assigned using the expected '.' to '/' mapping. In this way we turn: schema id='a.b.c' path='/a/b/c/' !-- common case -- schema id='x.y.z' !-- uncommon case -- to: schema id='a.b.c' !-- common case -- schema id='x.y.z' relocatable='yes'!-- uncommon case -- Even if we don't do #2, I think doing #1 might be useful. I don't have any evidence (even anecdotal) to support the idea that the current situation is confusing but it seems that a helpful warning explaining to the user that schema id='a.b.c' doesn't mean what they think may be useful... Thoughts? __**_ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-devel-**listhttps://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: d-feet pygi /gdbus port available for testing
Woohoo \o/ Thanks! 2012/10/14 Thomas Bechtold thomasbecht...@jpberlin.de Hi, I ported d-feet[1][2] from pygtk to pygi and from python-dbus to gdbus. The code is currently hosted on gitorious[3] and ready for testing. I'm in contact with the current maintainer (J5) and I'll move the code to git.gnome.org soon. So if nobody complains about the port, there will be a new d-feet release soon. Cheers, Tom [1] https://live.gnome.org/DFeet/ [2] https://bugzilla.gnome.org/show_bug.cgi?id=681093 [3] https://gitorious.org/d-feet/d-feet ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ropes and String Formatting
Hello Russell, First of all, don't get discouraged if you get no feedback, but it is really hard to get feedback in most communities if you present a proposal with no code. Note that you are asking our thoughts before you even mention what would be the benefits of GRopes, so it is really hard for us to judge its advantages over the ADTs we already have. In any case, I will encourage you to go ahead and write GRope as a standalone library (libgrope?), right after that, try to find a good usecase where you can show its benefits compared to other solutions. It seems to me that GRope could be a nice way to implement GtkTextBuffer, (obviously, this is in theory). As an excercise, once you have GRope implemented, port GtkTextBuffer so that it uses GRope underneath and write some benchmarks to check whether it is worth using it. If you achieve a better GtkTextBuffer using GRope, rest assured that it will be considered seriously by the GLib community. And if GRope doesn't happen to improve GtkTextBuffer, I am sure that you will learn a lot of valuable lessons along the way. Please keep us posted if you make any advancements, and don't be discouraged by the lack of response, just note that including GLib is a bit of a big deal, but that doesn't mean that you cannot write a GRope implementation that rocks and can be useful to a lot of people, so go ahead! 2012/5/21 Russell Harmon r...@eatnumber1.com I'm looking to implement two things which I think would be quite useful if included in glib. - Ropes [1] - Custom string formatting helper routines What are people's thoughts on this? I was doing a little prototyping and was having trouble deciding whether to have the string formatting helper routines take and return ropes (which would be algorithmically faster), or take and return gchar *s which would probably be faster on very small strings, depending on the specifics of the implementation. Or, do you guys not worry about performance on that level? I was also wondering about what you guys' policy on code simplicity vs performance is. String formatting routines (that take and return a gchar *) could be implemented relatively easily, but would be very inefficient with calls to realloc() on every conversion, or could be implemented much more efficiently but with a great deal more code. You can see an example of this in some code I wrote last year, [2] although I think I can do better than this example by a great deal. Lastly, would you guys even be interested in ropes and string formatting routines at all? Thanks Russell Harmon [1]: http://en.wikipedia.org/wiki/Rope_(computer_science) [2]: https://github.com/eatnumber1/getmntinfo/blob/master/getmntinfo.c#L314 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ropes and String Formatting
Thanks to kampstrup I just learned the meaning of groping and how unfortunate the name GRope is, I apologize! 2012/5/25 Alberto Ruiz ar...@gnome.org Hello Russell, First of all, don't get discouraged if you get no feedback, but it is really hard to get feedback in most communities if you present a proposal with no code. Note that you are asking our thoughts before you even mention what would be the benefits of GRopes, so it is really hard for us to judge its advantages over the ADTs we already have. In any case, I will encourage you to go ahead and write GRope as a standalone library (libgrope?), right after that, try to find a good usecase where you can show its benefits compared to other solutions. It seems to me that GRope could be a nice way to implement GtkTextBuffer, (obviously, this is in theory). As an excercise, once you have GRope implemented, port GtkTextBuffer so that it uses GRope underneath and write some benchmarks to check whether it is worth using it. If you achieve a better GtkTextBuffer using GRope, rest assured that it will be considered seriously by the GLib community. And if GRope doesn't happen to improve GtkTextBuffer, I am sure that you will learn a lot of valuable lessons along the way. Please keep us posted if you make any advancements, and don't be discouraged by the lack of response, just note that including GLib is a bit of a big deal, but that doesn't mean that you cannot write a GRope implementation that rocks and can be useful to a lot of people, so go ahead! 2012/5/21 Russell Harmon r...@eatnumber1.com I'm looking to implement two things which I think would be quite useful if included in glib. - Ropes [1] - Custom string formatting helper routines What are people's thoughts on this? I was doing a little prototyping and was having trouble deciding whether to have the string formatting helper routines take and return ropes (which would be algorithmically faster), or take and return gchar *s which would probably be faster on very small strings, depending on the specifics of the implementation. Or, do you guys not worry about performance on that level? I was also wondering about what you guys' policy on code simplicity vs performance is. String formatting routines (that take and return a gchar *) could be implemented relatively easily, but would be very inefficient with calls to realloc() on every conversion, or could be implemented much more efficiently but with a great deal more code. You can see an example of this in some code I wrote last year, [2] although I think I can do better than this example by a great deal. Lastly, would you guys even be interested in ropes and string formatting routines at all? Thanks Russell Harmon [1]: http://en.wikipedia.org/wiki/Rope_(computer_science) [2]: https://github.com/eatnumber1/getmntinfo/blob/master/getmntinfo.c#L314 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Commercial support page on gtk.org
I do wonder if Novell is actually offering Gtk+ support anymore, or whether we should refer them as SuSE (in case they want and they do actually offer such support?). Same question goes for RedHat, are they actually offering support to ISVs? 2012/3/19 Matthias Clasen matthias.cla...@gmail.com On Mon, Mar 19, 2012 at 11:12 AM, Martyn Russell mar...@lanedo.com wrote: If there are no major objections, I will push this by Friday this week or shortly after. Comments welcome, It looks fine to me, thanks for doing this. Only question I have is whether it is ok to list companies as 'providing gtk support' without explicitly asking them first. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME Development Network
Hi Thomas! Thanks a lot for your offer to help, I'm CCing gtk-devel for the rest of the hackers to follow this conversation and making sure we don't duplicate any work ;-) There are things you can help with along these lines. The first thing is, if you really want to help me, please spend some time learning django! I've been learning as I go, is not a big deal if you know pyhton already and I can certainly help. I have very limited time to work on this so I really need help with the core. You don't need to learn giraffe, I have that covered! On a more high level point of view, I think the best way you can help is by putting together an API documentation review plan for the GNOME project. We can start small and we will certainly need help, but writing guidelines on how someone can review the docs would be nice! (This could be like the HIG for API documentation X-) Now, before we do the guidelines we need to do some ground work to figure out what the most common quirks are, this means taking a library like GLib/GObject and going through it sctructure by structure, class by class and function by function, trying to figure out things like you mentioned (which functions should I use with this one, how do I get an object of class X from?) We can start with GObject itself and move from there! What do you think? Are you up for the task? Cheers, Alberto Ruiz 2012/2/16 Thomas H.P. Andersen pho...@gmail.com Hi Alberto, I just read your blog post. Really really cool stuff. I have been wanting to do something along the same lines myself. I do some .net programming at work and the online documentation and fine grained examples there always leave me wishing for the same for gobject/gtk. I have zero experience with django or giraffe but I would like to contribute with actual content. That is, small per-method examples and things like that. Random thoughts and ideas I have had about documentation: (sorry for just dumping my thoughts instead of patches) 1) Can useful information be extracted from the large corpus of code using the api's. Things like: a) Highlight most used/popular methods for the class b) Group methods together by how frequently they are used together on an object. E.g. for a GtkSpinner object the method gtk_spinner_start is often called just after a gtk_widget_show. After the GtkBuilder constructor the first call is often gtk_builder_add_from_file then often followed by gtk_builder_connect_signals etc etc 2) Direct links to cgit web interface for code using the api. Checking how other people use an api can help if the documentation was not clear enough. A poor man's documentation example if you like. I sometimes just grep another project (often gedit or epiphany) to check for neat tricks with a specific class/method. 3) Direct link to the implementation I often find myself digging in gtk/glib for api I am using. A direct link to the implementation could be cool. 4) Was this this documentation helpful? 1-5 stars rating. 5) Use code examples as unit tests Could help to make sure the examples are still correct and it should help to get more test coverage. - thomas -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding gtkparasite to gtk?
Hey, Has anyone stepped up to port it to Gtk+3? 2012/2/17 Christian Hergert ch...@dronelabs.com On Thu, 2012-02-16 at 10:47 -0800, John Ralls wrote: On Feb 16, 2012, at 9:00 AM, Colin Walters wrote: On Tue, 2012-02-14 at 16:25 +, Richard Hughes wrote: and the upstream seems unwilling to port to GTK3, Why? [Snip] It depends on pygtk, You answered your own question. I think the primary concern is that it be able to support both gtk2.x and gtk3.x. Especially given that VMware's products are gtk2.x. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding gtkparasite to gtk?
Big +1 2012/2/14 Richard Hughes hughsi...@gmail.com I think gtkparasite is a really useful tool for GTK developers. It's currently hosted in github, and the upstream seems unwilling to port to GTK3, and consequently there are over a dozen forks of the project in various states of maintenance. I'm going to suggest merging in gtkparasite to modules/ in gtk. This means it's kept up to date with the latest GTK codebase, and we can start to recommend its use to developers and hackers. So, any objections? Richard. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: touch events
2012/2/2 Benjamin Otte o...@gnome.org So from reading Matthias' mails it seems to me that this is the first step, so we should get this right first. We should have a good idea of where we want to go, but we don't need to merge the full multitouch branch to get touch events. So let's start small. Note that I do not have any touch-capable devices, so I have no way to test the things I'm suggesting here. All I can and will do for now is API review. Just FYI, if anyone wants to get a device to test this, the Apple magic trackpad works on Linux and it is really neat for testing. Chase Douglas and the other touch engineers in the System teams use it for the gesture support development in Ubuntu. It is a good workaround if you don't want to buy a whole multitouch capable tablet(pc). For now I'll only care about event delivery of touch events and ignore crossing events, pointer emulation and those. I do however care about portability to Windows and OS X. (I'll ignore Wayland because I assume it'll be similar/identical to X11). As a guidance, I've looked at the following documents: - X11 http://who-t.blogspot.com/2011/12/multitouch-in-x-getting-events.html http://who-t.blogspot.com/2012/01/multitouch-in-x-touch-grab-handling.html http://cgit.freedesktop.org/xorg/proto/inputproto/tree/specs/XI2proto.txt - Windows http://msdn.microsoft.com/en-us/library/windows/desktop/dd317321%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dd317334%28v=vs.85%29.aspx - OS X http://developer.apple.com/library/mac/#documentation/AppKit/Reference/NSTouch_Class/Reference/Reference.html - Qt (for reference) http://www.slideshare.net/qtbynokia/using-multitouch-and-gestures-with-qt http://developer.qt.nokia.com/doc/qt-4.8/qtouchevent.html As far as I understand, none of these are concerned with multitouch; multitouch is something that is implemented on top of this basic system by the machinery commonly known as gestures. In all of these, touch is implemented via touch sequences. A sequence is a list of events, always delivered like this: 1 BEGIN event 0 or more UPDATE events 1 END or CANCEL event Each of those events carries a designated ID that identifies the sequence. There are some differences however, and I'm not sure if we need to care about those right now or if we can think about them later: - CANCEL vs END may be a flag on a single END event (X11) or two separate events (OS X). (I personally prefer the OS X part, because cancelling vs performing an action is a very different thing). - Some operations on X11 require accepting a touch sequence (in particular for grabs). - Some update events distinguish between did move and did not move (OS X, Qt). The current multitouch patchset implements touch events by using GdkButtonEvent and GdkMotionEvent and appending a sequence id to them. Apart from the fact that I'm not sure if that's API stable (my guess would be hell no), I don't like that approach. The platforms above seem to agree with me. Qt, Windows and OS X have a custom TouchEvent for that purpose. I did not look at all yet at what contents a GdkTouchEvent should have and how references to previous events should be handled. My gut feeling says let the sequence take care of it, Qt says we'll give you a list of all motion points and lots of other points, too, I didn't look at other toolkits. I would also prefer the touch sequence to not be hardcoded as an integer, but encapsulated - a pointer typedef for example. This would allow adding features to touch sequences later on (like the accepting stuff from X11 grabs). That's it for the events. Some comments not directly related, but relevant to a patchset based on these ideas: - Qt has device type TouchScreen vs TouchPad. Should we have that? - I suppose just having a GDK_TOUCH_MASK is enough? Does this look sane? Or are there any platform issues? Did I miss anything? Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gir stability
I'd say that the entire API stability of bindings is not a minor issue vs. the stability of a new widget. 2012/1/31 Morten Welinder mort...@gnome.org This seems like a minor issue compared to GtkGrid 3.0 vs GtkGrid 3.2 incompatibilities. A could of attributes got swapped in-between those two versions. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
I think that if we were up to do this, we should go ahead and get rid of GtkTreeModel altogether and substitute it for something like libmodel. The data driven app situation in GObject/Gtk+ is quite sad at the moment and there's a lot of code that could be reused (like data/search filtering and data model backends) if we had a proper collection/data model API in place and used by the toolkit. 2012/1/13 Kristian Rietveld k...@loopnest.org On Jan 12, 2012, at 6:16 AM, Matthew Brush wrote: SIMPLE TREE and LIST It would be great to have simple GtkTree and GtkList widget sitting ontop of the extremely powerful GtkTreeView API for those many cases where you just need a basic tree or list box. The new widgets would not require a book[1] to explain how to use it. I saw a GtkTree in the API docs but it's deprecated, presumably because it doesn't sit ontop of the better tree view API. A couple of years ago I worked on an API and implementation of such a simple list/tree, using GtkTreeView internally. It never made it into GTK+ or bugzilla unfortunately and is catching dust on one of my machines. I still intend to dig up the code, document it and put it on a wiki somewhere for somebody to pick up and improve so that it can maybe be merged. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
Great stuff! Thanks a lot for the effort John, good job! :-) 2011/10/10 John Ralls jra...@ceridwen.us I've made a lot of progress on this in the last few weeks. The wiki pages are transferred, the gtk-osx, gtk-mac-integration, gtk-mac-bundler projects are in git.gnome and ftp.gnome, and Kris has gotten most of the patches reviewed and I've pushed them. Now to the web page. I've written a replacement for www.gtk.org/downloads/macos.php with a lot of editorial help from Martyn, and it's now ready for you all to review. Martyn has put up a preview at http://curlybeast.net:8080/download/macos.php Please have a look and comment either here or directly to me. I'd like to merge this into gtk-web master by Thursday. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
2011/9/8 Martyn Russell mar...@lanedo.com only allow downloading of separate packages. What I wished we had years ago when I was developing on Windows was an executable which installed GTK+ on the system for all apps (so I didn't have to package gtk+ inside my own project). That's a really bad idea for several reasons. First, we don't have the resources to test ABI compatibility on windows, there has been cases where some versions have crashed windows apps. Second, Windows is not as good at managing shared .dlls as Linux is. It can become a nightmare. You need to either wire up the Side by Side plumbing or mess with %PATH% to get things right, and both approaches have their own set of problems. In the Qt world and other toolkits, most people just bundle their dependencies. That's the standard and the right thing to do on Windows. Application developers are in charge of delivering a Gtk+ (and other deps) version that works for their app. Third, and the most important. Windows has no package manager. You should not delegate on users the responsibility of making sure that a working copy of GTK is installed. This is annoying enough with Java. A .zip bundle (and maybe some facilities to shove that into your app installer) is the best approach for now IMHO. If there is consent amongst the team and this is available, I can set up the gtk.org pages for this. -- Regards, Martyn Founder and CEO of Lanedo GmbH. __**_ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/**listinfo/gtk-devel-listhttp://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: GTK and OSX: a call to sanity
Forgot to Reply All :-) -- Forwarded message -- From: Alberto Ruiz ar...@gnome.org Date: 2011/9/8 Subject: Re: GTK and OSX: a call to sanity To: John Ralls jra...@ceridwen.us 2011/9/8 John Ralls jra...@ceridwen.us The rest of Gtk-OSX isn't Gtk. It's a build system using jhbuild with its own modulesets, a python script for making application bundles, and a few other bits and pieces, including gtk-quartz-engine, a Cocoa HIT theme engine which I haven't touched since Richard Hult left it to me except to ensure that the github and git.gnome.org repos are the same. I don't even know if it works with Gtk3. It doesn't work with Gtk3. Do you have any patches for jhbuild or is it just the moduleset? If it is just a module set feel free to maintain it in jhbuild/modulesets/other. I maintain a wayland moduleset there. What's the cost of keeping those bits on Sourceforge vs. Gnome.org? ISTM it will cost me a lot of time and effort to move them into gnome.org with no real benefit to anyone except Emmanuele who can't seem to get an SF account. (Emmanuele, if you really want to sort that out, email me directly and I'll see what I can do to help.) That is not true at all. There are several benefits for a lot of people, specially you. The main one is that everybody would be working in the same place, we are very few people and we need to pool resources. The other benefit is, most people file bugs against bugzilla.gnome.org when they find a problem in Gtk+ (on whatever platform). When I started my Windows efforts, I did exactly what you did. Under the assumption that nobody cared about Windows, I ended up creating my own mailing list, and trying to do things on my own. That's the worst way to generate traction. If you want help, and if you want people to care, keep them in the loop. The problem here is that in one hand, most core Gtk+ developers are used to a certain workflow, a certain set of tools... if you want their help, you're going to have to make their lifes easier (and believe me, they want to help you, despite the tone of certain emails). On the other hand, and this is the important bit, fragmentation of the project resources is a huge problem. It is already bad with all the different bindings (pygtk, gtkmm, etc...). Something as fundamental as Windows and Mac OS X support should be visible within the same place (the gtk.org website, gnome's bugzilla, gnome's git repos). This is not about core Gtk+ developers not wanting to create an SF account, most of them probably have one already. This is about pooling resources and learning to work together. Regards, John Ralls [1] https://bugzilla.gnome.org/show_bug.cgi?id=571582 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug 658098 - no way to specify optional domain field in gvfs password dialog
Why are you changing the value of HAS_DOMAIN ? - G_ASK_PASSWORD_NEED_DOMAIN = (1 2), + G_ASK_PASSWORD_HAS_DOMAIN = (1 2), G_ASK_PASSWORD_SAVING_SUPPORTED= (1 3), - G_ASK_PASSWORD_ANONYMOUS_SUPPORTED = (1 4) + G_ASK_PASSWORD_ANONYMOUS_SUPPORTED = (1 4), + G_ASK_PASSWORD_NEED_DOMAIN = (1 5) } GAskPasswordFlags; 2011/9/6 Michal Suchanek hramr...@centrum.cz Hello, The fix to this issue is quite trivial but requires patching all three of glib, gvfs, gtk. Also it is not quite obvious that replacing the old NEED_DOMAIN with HAS_DOMAIN is the best thing. Any opinions? Thanks Michal ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ team meeting at guadec
I'll be only there during the core days 6th-9th (leaving on 9th afternoon) not during the BoF days. If that's a problem for the rest I don't mind attending remotely or something (though I suspect I'm not the only one in this situation). Cheers, Alberto Ruiz 2011/7/27 Matthias Clasen matthias.cla...@gmail.com Hey, I have been slacking off and not pushing for team meetings recently, and I haven't even looked at the guadec schedule until today. But I guess better late than never: should we aim for a gtk team meeting at guadec ? If so, what day would work best for everybody ? ___ 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 http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Trimming gdk-pixbuf repository
2011/5/24 Yasushi SHOJI ya...@atmark-techno.com: At Sat, 21 May 2011 03:37:38 +0200, Olav Vitters wrote: On Thu, Mar 17, 2011 at 09:06:32PM +, Alberto Ruiz wrote: I am looking for comments from git experts on any of the operations I'm doing and how feasible would be to rewrite the git.gnome.org repository. The resulting repository can be found in my github site[0]. Any git experts who can look at this again? https://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00066.html I'm not a git expert per se, but I would be against the idea if I was asked for the following reasons: - the trim changes the SHA1 ID check the commit with PIXBUF_0_0 tag; the cuurent gdk-pixbuf repo on git.gnome.org has f0723b00 but the trimed one has 534df8c. this is due to git's _feature_. That shouldn't be a big deal given the bandwidth savings. - we usually clone a few times most of us do not re-clone every time we hack on it. rather, we keep the cloned repo handy and reuse all the time. _You_ usually do not re-clone, I have several test machines, and those get wiped once in a while, and every time I have to setup a new environment is a PITA. In any case, what worries me the most is bandwidth usage (though I don't have any numbers), it seems weird to me that we are moving away from tar.gz/bz2 to save bandwidth and still we waste so much bandwidth cloning gtk3/2/gdk-pixbuf - there is another way to reduce the transfer size (if you have gtk+ repo) you can tell git to reference gtk+ git repo when you clone gdk-pixbuf $ /usr/bin/time git clone --reference gtk+ git://git.gnome.org/gdk-pixbuf Cloning into gdk-pixbuf... remote: Counting objects: 30651, done. remote: Compressing objects: 100% (7683/7683), done. remote: Total 30184 (delta 25544), reused 26364 (delta 22362) Receiving objects: 100% (30184/30184), 36.57 MiB | 375 KiB/s, done. Resolving deltas: 100% (25544/25544), completed with 417 local objects. 18.33user 1.47system 2:31.32elapsed 13%CPU (0avgtext+0avgdata 430768maxresident)k 541864inputs+210072outputs (102major+51069minor)pagefaults 0swaps I'm not sure there's a sensible way to do this in jhbuild it is bigger than trimed one (29.40 MiB) but 6 MiB is negligible IMO. here is the log of full clone via my slow wireless connection, just in case. $ /usr/bin/time git clone git://git.gnome.org/gdk-pixbuf Cloning into gdk-pixbuf... remote: Counting objects: 229825, done. remote: Compressing objects: 100% (33082/33082), done. remote: Total 229825 (delta 197326), reused 228509 (delta 196355) Receiving objects: 100% (229825/229825), 133.96 MiB | 413 KiB/s, done. Resolving deltas: 100% (197326/197326), done. 55.00user 3.84system 5:41.92elapsed 17%CPU (0avgtext+0avgdata 110496maxresident)k 12872inputs+575600outputs (10major+15953minor)pagefaults 0swaps just my two cents. -- yashi -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Introspection] Trying to remove warnings for Pango-1.0.gir: Boxed or skip?
2011/4/26 Behdad Esfahbod beh...@behdad.org: On 04/25/11 19:27, Alberto Ruiz wrote: Hi, I removed most warnings while generating Pango-1.0.gir, however, there's a last batch of warnings I'm not sure how to get rid of: http://pastebin.com/V0ZDRg3r Thanks Alberto! Np! I've been lurking around and all that I can gather is that some of those types are not present in the gir, though I'm not sure why. Any pointers are welcome. I see two different cases: - The various PangoAttr* are not boxed separately as they subclass PangoAttribute without a real object system. See bug 646788 for example. Right, I'm not sure how to approach this gi-wise, I will try to pick walters' brain on this and see how to go ahead. - The other cases (PangoEngineShape, etc) are protected behind PANGO_ENABLE_ENGINE, and perhaps some behind PANGO_ENABLE_BACKEND. Those APIs are less stable than the base API and may change between release cycles. Not sure they are worth binding. (ie, do we support someone implementing a Pango backend in Python? Maybe...) If that's the case, I rather do (skip) on them and enable them in case anybody comes up with a compelling need :-) Thanks a lot for the feedback Behdad -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[Introspection] Trying to remove warnings for Pango-1.0.gir: Boxed or skip?
Hi, I removed most warnings while generating Pango-1.0.gir, however, there's a last batch of warnings I'm not sure how to get rid of: http://pastebin.com/V0ZDRg3r I've been lurking around and all that I can gather is that some of those types are not present in the gir, though I'm not sure why. Any pointers are welcome. Thanks! -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
2011/4/17 David Zeuthen zeut...@gmail.com: Honestly, I'm not that interested in solving the make relocatable app providing plug-ins work without installing the app use-case work outside Linux. FWIW, even on Linux, I'm not even sure it's something worth worry about - for the few cases where you need this (such as when installing a MP3 or H264 decoder (e.g. a GStreamer plug-in)), it's fine just using the platform mechanism (e.g. RPM or DEB). David, I'm afraid it's not just fine for several reasons: 1. If you want to make your app widely available to different distributions, you need to learn how to create your package for each one of them (and each distro has its own level of difficulty when it comes to create a good package). This makes the getting your apps to the users story really BAD for GNOME. You can get an app up and running in Android and OSX in one or two days if it is really simple, hitting the appstores is a matter of barely a week. Getting to the users on Linux can take months. 2. A badly written package can break your package databse in the long run, (there's plenty of stories like this in the context of PPAs in Ubuntu), or mess up with your dependencies in critical ways that the user won't be able to solve. Relying on the system packaging to deploy apps is just broken. Adobe AIR in Ubuntu has broken my system a few times while messing with apps. Creating well formed packages and maintaining them is less obvious thatn you think. 3. You may need your own version of several platform libraries (such as Gtk+). Or ship your own and not having to worry of those being provided by the distro. Again, this story is pretty BAD when you try to do things this way. You may give examples of success in this approach by Google or Dropbox where things are mostly okay. But that's because they do a really good job. I don't want to rely my system integrity on the ability of all application developers to do a really good job on .DEB/.RPM/... packaging. So yeah, .RPM/.DEB is absolutely fine for system level components (platform, shell...). But for applications, I have to say I really don't agree at all that it is the right mechanism, unless you come up with a sandboxed approach for apps installed by the user. -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk3.0
Because there is not enough people taking care of that backend and it was broken most of the time. 2011/3/19 zhangzhao130181 zhangzhao130...@126.com: Why gtk3.0 or newer does't support DirectFB? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Trimming gdk-pixbuf repository
Hello everbody,
I have been playing around with trimming the gdk-pixbuf repository as
it carries all the changes from Gtk+ 2.x before it was split.
I have used the script attached, it basically figures out which files
have been removed and removes all the content related to them from the
history. Commits that are not affecting any existing files are gone.
It would be nice if someone with a deeper knowledge of git could
review it, everything seems fine on my side.
There's one problem with the script, after I run git gc --prune
--aggressive the loose objects won't go away. However once I push the
repository to github and clone again, everything is stripped from the
repo. Afterwards it's tripped and the tags can be restored. (see the
bottom of the shell script and the python script for details on this).
I am looking for comments from git experts on any of the operations
I'm doing and how feasible would be to rewrite the git.gnome.org
repository. The resulting repository can be found in my github
site[0].
I've done a test of cloning it over git and this is the result:
aruiz@watchover:~/src$ time git clone g...@github.com:aruiz/gdk-pixbuf-trim.git
Initialized empty Git repository in /home/aruiz/src/gdk-pixbuf-trim/.git/
remote: Counting objects: 27243, done.
remote: Compressing objects: 100% (4500/4500), done.
remote: Total 27243 (delta 22645), reused 27243 (delta 22645)
Receiving objects: 100% (27243/27243), 29.40 MiB | 789 KiB/s, done.
Resolving deltas: 100% (22645/22645), done.
real0m47.499s
user0m9.473s
sys 0m0.788s
---
aruiz@watchover:~/src$ time git clone git://git.gnome.org/gdk-pixbuf
Initialized empty Git repository in /home/aruiz/src/gdk-pixbuf/.git/
remote: Counting objects: 229709, done.
remote: Compressing objects: 100% (32966/32966), done.
remote: Total 229709 (delta 197249), reused 228507 (delta 196355)
Receiving objects: 100% (229709/229709), 133.87 MiB | 495 KiB/s, done.
Resolving deltas: 100% (197249/197249), done.
real5m21.110s
user0m57.792s
sys 0m4.900s
That's a difference of 104 Mb of transfer and 4:30ish minutes in my
rather fast ADSL. I think this would be a major improvement for
anybody cloning that repo.
[0] https://github.com/aruiz/gdk-pixbuf-trim
--
Un saludo,
Alberto Ruiz
script
Description: Binary data
commitlist = [i.strip() for i in open ('/tmp/tmp_commitlist', 'r').readlines ()]
new_commitlist = [i.strip() for i in open ('/tmp/tmp_new_commitlist', 'r').readlines ()]
tagmaplist = [i.strip().split (' ', 1) for i in open ('/tmp/tmp_tagmap', 'r').readlines ()]
def find_candidate (sortedindexes, index):
for i in sortedindexes:
if i = index:
return i
return None
#We turn the tag/map list into a dictionary
tagmap = {}
for i in tagmaplist:
tagmap[i[1]] = i[0]
#We create a map of the index of each remaining ref in the original repo
sortedindexes = [commitlist.index(commit) for commit in new_commitlist]
new_tagmap = {}
for tag in tagmap.keys():
#We get the original index of each
index = commitlist.index(tagmap[tag])
candidate = find_candidate (sortedindexes, index)
if not candidate:
continue
# print %s - %s : %s % (tagmap[tag], commitlist[candidate], tag)
new_tagmap[tag] = commitlist[candidate]
for tag in new_tagmap.keys():
print git tag %s %s % (tag, new_tagmap[tag])
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)
2011/3/7 Matthias Clasen matthias.cla...@gmail.com: On Mon, Mar 7, 2011 at 6:17 AM, Tristan Van Berkom trista...@openismus.com wrote: b.) It's damn easy to make GApplication at least startup correctly, run the main loop and just not use any IPC, it's the least I think that one can expect. Then lets the patch already, instead of needlessly prolonging this thread even further... +1 -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Patch for gdk-pixbuf ICO regression
Hi Damian, first of all, thanks for spotting this and taking the time to work on a patch, the standard way to submit patches for proposal is bugzilla.gnome.org, please file a bug in bugzilla and attach the patch to it. Cheers, Alberto 2010/9/9 Damjan Jovanovic damjan@gmail.com: Hi The FreeDesktop.org shared MIME database now identifies .ico files as image/vnd.microsoft.icon, and since gdk-pixbuf doesn't list that as a MIME type, libgnome-desktop no longer wants to thumbnail .ico files, and (at least) Nautilus thus displays no thumbnail for .ico files. The attached 1 line patch adds image/vnd.microsoft.icon to the MIME types listed by the gdk-pixbuf ICO loader and fixes the problem. Thank you Damjan Jovanovic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.26 release plans (and GApplication)
Hi Ryan and the rest of the Gtk+ team, Sorry for not attending the meeting today, I have an exam next week and I really have to focus. I have a question though, regarding the situation with GApplication: 2010/9/7 Ryan Lortie de...@desrt.ca: - go back to libunique (which is GDBus-enabled these days) - copy-paste today's GApplication code into your application - something else Would it be possible to move the current GApplication code to which a lot of apps are already ported to an external library somehow, or does this piece of code need to be inside GLib? If that is the case and the R-T would be fine with adding it as an external-dep, that would give us some advantages: 1) People who have already done the porting, won't be as pissed off as they are now. 2) We would have a more flexible place to play with the API in conjunction with the app developers. 3) Once everybody is happy with the API, we move the module back. I am totally unfamiliar with the technical implications of such proposal, but from a module maintainer perspective, I think this would alleviate some of the pain that removing this completely is going to cause. My 2 cents. -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
2010/9/4 Emmanuele Bassi eba...@gmail.com: Well, since currently gdk-pixbuf comes inside Gtk+, and Gtk+ depends on cairo. this is not true any more, since GDK-Pixbuf has been split from GTK+ and it's a separate library once again. Which is the actual point of my argument :P ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hello there,
at college, we used get_pixels for concurrency assignments where we
used Ada. (Histogram analysis, shape detection and whatnot)
The problem I see with removing this is that you actually need to make
a roundtrip from the GDK API to cairo_get_surface - cairo_get_data
which would not be a very obvious step from the API user point of
view.
If we are trying to keep things cairo internally, can't we just leave
get_pixels as a wrapper around cairo's get_surface/get_data if that's
how people are going to have to use it anyway?
Cheers,
Alberto
2010/9/3 Andrew Cowie and...@operationaldynamics.com:
On Thu, 2010-09-02 at 19:24 -0400, Havoc Pennington wrote:
We deprecate get_pixels() which is the only call that can force the
old-style representation to be created. If you do use get_pixels(),
what's going to happen is...
Deprecate¹ implies removal at either GTK 3.0 or GTK 4.0, right?
So I guess the question I have is is there ever a legitimate usage to
get the individual pixels.
Our binding of this right now is:
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gdk/Pixbuf.html#getPixels()
which is mostly used by us for testing; I couldn't begin to guess what
other people have used it for; I do know one crew that actually did some
image recognition work (feeding some other library from these byte[]).
We can kiss gdk_pixbuf_get_pixels() goodbye, no problem, but I'm just
curious what someone would replace it with... draw to a Cairo image
surface, save that to a PNG and then load it and... oh wait. :)
As usually happens across the language barrier, we had to copy the array
anyway, so I'm not really fussed where we get it from. Or, are we
advised to tell developers no more access to an image's pixels?
{shrug}
AfC
Sydney
¹ deprecate of course means don't use this it's been replaced or
just plain don't use it but in GTK during the long lifespan of 2.x
we've also used it to mean we'd rather you didn't use it but it's still
ok... because (until the last ~18 months) we were in
ain't-never-ever-gonna-remove-functions mode.
Now we're actually removing stuff! Who would have thunk it :)
I think there's some inconsistency in our library as a result of this. A
number of times over the last few months Javier has had his enthusiasm
pushed back when he's seen rather you didn't use this, not known it's
still ok, and thought it should be removed only to be told to leave it
alone.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Un saludo,
Alberto Ruiz
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
2010/9/3 Christophe Fergeau cferg...@gmail.com: Hi, On Thu, Sep 02, 2010 at 07:57:44PM -0400, Matthias Clasen wrote: One downside that you've mentioned earlier is that with this approach, gdk-pixbuf grows a cairo (and thus libX11) dependency. That might inconvenience a few gdk-pixbuf users. But the one I know offhand, librsvg, already has a cairo dependency (via pango) anyway. So, probably not a big problem. For what it's worth, libgpod has a gdk-pixbuf dependency and no cairo dep, and people complain from time to time about that dependency (though that's mainly on distros where gdk-pixbuf is in the same package as gtk+, which will no longer be the case with gtk3). So I don't know how they will react to an additional cairo dep ;) Well, since currently gdk-pixbuf comes inside Gtk+, and Gtk+ depends on cairo. In effect, you already depend on cairo. So in effect, you will have one dependency less, Gtk+. This should make your dependency-phobic users happy. On the other hand, a GdkPixbuf handling more formats than the current one would be really useful since for now it's not possible to easily transfer pixel data from a GdkPixbuf to a QImage (conversion is needed). Hopefully with the additional pixel formats that are suggested here, this will become easier. Christophe ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
that they can distribute to the majority platforms (sorry, that most certainly does *not* include X11) should look elsewhere. I don't know why Gtk-OSX isn't on Gnome.org. (Gtk.org is just a PR website; all of the development resources are provided by Gnome.org.) The project was originated by Richard Hult, who had AFAICT full privs on Gnome for project creation both in VCS and on Bugzilla, but he chose to use Github for VCS and to provide PR, documentation, and support on his former company's (Imendio.AB) website, and downloads at a private domain (www.gtk-macosx.org). It's now on Sourceforge because when Richard decided with his partner wind up Imendio and to withdraw from Gtk+, he asked on his forum for someone to take over maintaining the build system. I bit, and after some probing discovered that he'd not been successful in getting anyone to take over *any* of the components; he had some hope that one or more of his former Imendio employees who were still involved with Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered that it would take some time and a lot of work to get a project started at Gnome.org. It took a week at Sourceforge, and only that long because I did a hostile takeover of a moribund project that was a fork of Gtk 1 whose name I wanted. Pidgin doesn't support quartz; the OSX download link on their website is for Fink. GIMP doesn't have their own OSX port; rather, they recommend either MacPorts or http://sourceforge.net/projects/gimponosx/. It's probably buildable with quartz on MacPorts -- which also provides Gtk-OSX's ige-mac-integration package. Gimponosx simply wraps up a Macports build into a Mac-friendly dmg. (There's also a GIMP module in Gtk-OSX which works fine, though it won't build 64-bit because they incorporate a copy of the old Carbon ige-mac-menu code in their source tree. I should fix that and send them a patch.) What work from either is supposed to form the basis of a sanctioned Gtk+ distribution on OSX? Regards, John Ralls ___ 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 http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
Hello Paul, 2010/8/30 Paul Davis p...@linuxaudiosystems.com: As long as the people working on GTK-OSX do it with a us-vs-them attitude (like you display here by talking about the GTK developers in third person), things are not going to change. If you start considering yourself part of the team and actively engage, things can and will change. this is pretty obnoxious. i don't know how tor manages to keep his temper with the windows port, This is a resources issue, most of the existing developers are focused on Linux, and they have no resources/time to focus on Windows development. I have contributed several improvements to improve the Windows support and I have felt more than welcome to do so. So this is not obnoxious at all, if the people with the focus and time actually helped, the situation would be a lot better, what you can't ask is that the development of Gtk+ to be stalled until someone shows up and helps with the Windows or Mac OS X port to make a given change. So yeah, I totally support Matthias here, if you want a better situation, feel free to JFDI. -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
Hi John, 2010/8/27 John Ralls jra...@ceridwen.us: Gtk-OSX is *not* part of Gtk+. Maybe that's something we should fix? Resources around Gtk+ are already way too fragmented. -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
I'm not even reading the whole email: +1 !!! :-) 2010/8/24 Tristan Van Berkom trista...@openismus.com: On Wed, 2010-08-25 at 02:42 +0900, Tristan Van Berkom wrote: [...] PS: I've been trying to send this mail all day, at this point from several email addresses... I'm dropping the .tgz attachment and will follow up with another mail after uploading it somewhere if this email does indeed hit the mailing list. Looks like it finally went through after removing the attachment, you can build and try the demo by simply downloading it from here: http://people.gnome.org/~tvb/eggwrapbox.tgz Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup
2010/8/16 Jean Brefort jean.bref...@normalesup.org: Hi, Sorry to come late to this thread, but I'd like to know how you intend to support things that can't be rendered using cairo? Just like a 3D OpenGL scene. I'm not sure gtkglext would still work. I hope I'm missing something... That's an easy one. Enabling cairo to render on more places :P Regards, Jean Le jeudi 22 juillet 2010 à 04:54 +0200, Benjamin Otte a écrit : Hi, As many of you have already noticed, I've been frantically hacking away on my Gtk rendering-cleanup branch[1]. The branch is an attempt to move all GTK drawing to Cairo and remove all the outdated APIs that exist for rendering, including, but not limited to: - GdkRGB - GdkImage - gdk_draw_*() - GdkPangoRenderer - GdkGC More things could be removed (GdkColormap and GdkColor.pixel come to mind), but those aren't urgent for 3.0 IMO, so I didn't remove them. I did do this because the task of implementing and maintaining such a complex rendering API as Gdk2.0 provides is a very daunting task and looking at the non-X11 backends also quite complex, while Cairo provides a much smaller API and has fallbacks for almost everything. The work is done and the code runs now. Well, at least testgtk and gtk3-demo do. On X11. I'd be happy if others could take it for a spin and find issues with it or even have a go at Quartz and Win32 code. Even though this is a huge amount of API that is removed - it's close to 30.000 lines of code including docs - there don't seem to be a lot of users inside GNOME. Most of the users are really old parts of the code and in those cases switching to Cairo should be a reasonably easy. In fact, a lot of the functions can be replaced using similar functions from Cairo in a copy/paste style. Also, I'd like to point out that no API was changed. I only removed functions. So a proper transition from Gtk2 using deprecations is easily possible. So what do I intend to do next? 1) Port some applications - the bigger users - to not use these functions anymore. That way I'll both review my branch and get some apps fixed. 2) Cherry-pick the cleanup work into master and gtk-2-22 3) Get an ok to merge the API cleanup to master (or at least partially) and deprecate related functions for 2.22. The work is tracked in bug 624255[2] and further discussions should happen there. This mail is just intended to make everyone aware of the effort and to answer any questions you might have. Also, I'm aware that we are very close to a release. I'd understand if that'd make people not want to merge it. But I think it's worth it and the impact is very small compared to the other changes in Gtk3. And last but not least, some diffstats: Whole patchset: 146 files changed, 2730 insertions(+), 29384 deletions(-) gdk/ subdirectory: 64 files changed, 590 insertions(+), 22215 deletions(-) This should prove that it's pretty much just removing code. gtk/ subdirectory: 37 files changed, 1866 insertions(+), 3373 deletions(-) Half of that is fixing the default style, the other half is updating widgets to use Cairo. Cheers, Benjamin 1: http://git.gnome.org/browse/gtk+/log/?h=rendering-cleanup 2: https://bugzilla.gnome.org/show_bug.cgi?id=624255 ___ 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 http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
2010/6/15 Olav Vitters o...@vitters.nl: On Tue, Jun 15, 2010 at 12:10:58PM +0200, Tshepang Lekhonkhobe wrote: Yeah, I get it, but here's the point: it isn't nice when a maintainer says unlikely without giving even one reason, leaving the rest of us to guess (EG, that's most likely the reason). Can we stop this discussion now or take it off list please? +1 Thanks. -- Regards, Olav (moderator) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Website proposal for usability
Vinicius and myself have been working on a design for the website for the Gtk+ 3.0 release. I don't have his stuff around unfortunately (it's on the dropbox folder from the design team). That beign said, I don't want to stop any improvements, however, I have a few things to note about this design: The chosen font, Charcoal, comes from apple and as far as I know it does not come with any Linux distro that I'm aware of. An open font would be better. We tend to use Bitstream Vera Sans within the GNOME brand. Replacing the + sign with the Gtk+ logo is cute but not a very good idea IMHO, the logo loses it's relevance compared to gtk.org as it is now, and the name of the toolkit becomes not obvious. I don't like the fact that the news are more relevant than the explanation of what Gtk+ is, and the fact that ther e are no screenshots or anything to get an idea really quickly of what Gtk+ is all about _and_ how to use it. Vinicius, can you post somewhere the template you've been work at so that we can coordinate our efforts with the awesome work Devin has been doing? 2010/8/12 Devin Samarin eboyj...@gmail.com: On Thu, Aug 12, 2010 at 12:21 AM, Martyn Russell mar...@lanedo.com wrote: I like some of the proposed changes here. There are some other things that I think need changing (which were there before) such as the NEWS on the main page. It just doesn't get updated enough. Cool, I'm glad that you like it. :) The news on the front page is actually mirroring anything that is posted on http://blogs.gnome.org/gtk/ so if someone posts a message there, it will be included automatically on the main page. I didn't mention, but on the documentation page, some of the links are old and broken, so I removed the broken ones. If no one else here has any problems with the link you provided, we can just go ahead and make the changes after I have done a more thorough review. Okay, I have included links at the bottom so you can go ahead and take a look at the source code. Thanks again for doing this work! My pleasure! :) Devin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkRange API is incomplete
2010/7/27 Krzysztof Kosiński tweenk...@gmail.com: Hello Here is my use use case (in Inkscape). I have a set of sliders (GtkScale) that control some values in the document. I want to update the view of the document in real time, but only push the change on the undo stack when the drag is finished. But the only signal I can connect to is value-changed. When I connect to it, I have only two choices: 1. Update policy GTK_UPDATE_DISCONTINUOUS. This will give me correct undo behavior but won't update the display in real time. 2. Update policy GTK_UPDATE_CONTINUOUS. This will update the display correctly but will flood the undo stack with partial changes. The problem would be solved if there was some additional signal that would only be emitted when the user finishes the drag, or when the slider is moved using the keyboard. It could be called value-set. Essentially, it should be emitted after the value-changed signal whenever the value-changed signal would be emitted if the update policy was GTK_UPDATE_DISCONTINUOUS. Here's the relevant bug report from our tracker. https://bugs.launchpad.net/inkscape/+bug/579932 Can't you just connect to two different signal handlers one for the update and one for the undo stack? Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkRange API is incomplete
2010/7/27 Tadej Borovšak tadeb...@gmail.com: Hi. Can't you just connect to two different signal handlers one for the update and one for the undo stack? There is only one signal (GtkRange::value-changed) available. Unfortunately, GtkRange's internals are one huge pile of ... and adding another signal would not be that easy. Maybe you can combine all ::value-changed signal emission in certain time interval into one undo action? Hi there, You can just connect to the GtkRange's GtkAdjustment value-changed signal for the view update. Tadej -- Tadej Borovšak tadeboro.blogspot.com tadeb...@gmail.com tadej.borov...@gmail.com -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkScrollbar marker API discussion
Hello there, I have updated the patch, it now compiles against master and it contains the theming API hints that thos suggested: https://bugzilla.gnome.org/show_bug.cgi?id=623712 I think the patch is pretty much ready, I have tested it with different engines, some engines will have to do some work to prettify the result, but other than that I think it's there. It'll be really nice if someone can review it :-) 2010/7/16 Alberto Ruiz ar...@gnome.org: 2010/7/15 Thomas Wood t...@gnome.org: On Thu, 2010-07-15 at 23:40 +0100, Alberto Ruiz wrote: Hey guys, I've finally come up with a patch to implement this: https://bugzilla.gnome.org/show_bug.cgi?id=623712 The patch basically calls range's expose from scrollbar, and then paint the markers on top, once that's done, the slider is painted again on top. If there's anyone with the Nimbus theme or other theme with non sqared sliders, please let me know how it behaves. Actually, passing an appropriate detail string would be enough to let engines know that they are painting a mark. That would allow theme authors to choose whether to special case it or not. Also, maybe gtk_paint_flat_box() is more appropriate here? That's a good idea actually, will update the patch during the weekend :-) Regards, Thomas -- Un saludo, Alberto Ruiz -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkScrollbar marker API discussion
Hey guys, I've finally come up with a patch to implement this: https://bugzilla.gnome.org/show_bug.cgi?id=623712 The patch basically calls range's expose from scrollbar, and then paint the markers on top, once that's done, the slider is painted again on top. If there's anyone with the Nimbus theme or other theme with non sqared sliders, please let me know how it behaves. The patch adds simple marker support, no different classes/colours or tooltip strings. Honestly I think this API solves 90% of the problem and the code is maintaneable enough, plus adding themeable markers would be a nightmare implementation wise, it'll be a pain for themers and make the API more complicated, I don't see any other usecase than the IDE one for this and the theming API is due to significantly change during 3.x, if people _really_ want themeable markers, we should add enough on the public API for people to subclass and implement their own marker support. Feedback and reviewers are welcome :-) 2010/7/8 Alberto Ruiz ar...@gnome.org: 2010/7/7 Thomas Wood t...@gnome.org: On Wed, 2010-07-07 at 00:42 +0100, Alberto Ruiz wrote: Hi Gtk+ hackers, The marker addition call would look something like this: gtk_scrollbar_add_mark (GtkScrollbar *scrollbar, gdouble mark, gchar* mark_class); There would also be some stock markers with default colours. mark_class can be null and the default highlight colour will be used. Again, how and where to set and extend the colour mapping is sort of a blurry spot to me. It's probably important to get the theme integration correct here, so people can adjust the default highlight colours so that they don't clash with any other custom colours. Also, a different theme may want to draw markers in some new fancy way, so it might be important to make sure the marker information is available when the theme draws the scrollbar background. Alternatively, we could add a new marker drawing function in GtkStyle, but ideally we want to move away from using abstract drawing methods. Regards, Thomas Hi Thomas, I'm gonna try to find some time during next week to put together a patch and propose an initial API. Working from there would be a lot easier for me. If adding custom colours is gonna be a hassle theming wise I might consider dropping support for that and just offer generic search match support similar to what GtkScale does but without any string. -- Un saludo, Alberto Ruiz -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkScrollbar marker API discussion
2010/7/15 Thomas Wood t...@gnome.org: On Thu, 2010-07-15 at 23:40 +0100, Alberto Ruiz wrote: Hey guys, I've finally come up with a patch to implement this: https://bugzilla.gnome.org/show_bug.cgi?id=623712 The patch basically calls range's expose from scrollbar, and then paint the markers on top, once that's done, the slider is painted again on top. If there's anyone with the Nimbus theme or other theme with non sqared sliders, please let me know how it behaves. Actually, passing an appropriate detail string would be enough to let engines know that they are painting a mark. That would allow theme authors to choose whether to special case it or not. Also, maybe gtk_paint_flat_box() is more appropriate here? That's a good idea actually, will update the patch during the weekend :-) Regards, Thomas -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkScrollbar marker API discussion
2010/7/7 Thomas Wood t...@gnome.org: On Wed, 2010-07-07 at 00:42 +0100, Alberto Ruiz wrote: Hi Gtk+ hackers, The marker addition call would look something like this: gtk_scrollbar_add_mark (GtkScrollbar *scrollbar, gdouble mark, gchar* mark_class); There would also be some stock markers with default colours. mark_class can be null and the default highlight colour will be used. Again, how and where to set and extend the colour mapping is sort of a blurry spot to me. It's probably important to get the theme integration correct here, so people can adjust the default highlight colours so that they don't clash with any other custom colours. Also, a different theme may want to draw markers in some new fancy way, so it might be important to make sure the marker information is available when the theme draws the scrollbar background. Alternatively, we could add a new marker drawing function in GtkStyle, but ideally we want to move away from using abstract drawing methods. Regards, Thomas Hi Thomas, I'm gonna try to find some time during next week to put together a patch and propose an initial API. Working from there would be a lot easier for me. If adding custom colours is gonna be a hassle theming wise I might consider dropping support for that and just offer generic search match support similar to what GtkScale does but without any string. -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [pygtk] PyGtk and gtk-3.0 compatibility
list py...@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/ -- Gerald Britton ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkScrollbar marker API discussion
Hi Gtk+ hackers, today in the Gtk+ meeting we discussed the addition of a marker API to GtkScrollbar, the idea is to add Google Chrome style markers to the trough of the scrollbar to hint users on where to find multiple matches on an area. Right now the lack of access to details of the GtkRange's internal structure that stores the trough and slider geometry blocks this API adition. The plan right now would be: * Add an internal accessor to GtkRange's geometry structure (see #623711)[0] * Override GtkRange's expose and paint the markers on top, repaint the slider after that. * Add support for different classes of markers, with a string id for each class, and a colour map for each string. The marker addition call would look something like this: gtk_scrollbar_add_mark (GtkScrollbar *scrollbar, gdouble mark, gchar* mark_class); There would also be some stock markers with default colours. mark_class can be null and the default highlight colour will be used. Again, how and where to set and extend the colour mapping is sort of a blurry spot to me. Suggestions and help are more than welcome! [0] https://bugzilla.gnome.org/show_bug.cgi?id=623711 [1] https://bugzilla.gnome.org/show_bug.cgi?id=623712 -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
2010/6/14 Andrew Ziem ahz...@gmail.com: Would GTK+ upstream accept patches to disable GTK+ features? For example, ./configure --disable-file-chooser-disable would make the GtkFileChooser() an empty stub. I ship GTK+ in my application's Windows installer, and I'd like to shrink GTK+ because my application's dependencies are ~95% of the installer size and GTK+ is about half. I tried other methods [1] with mixed results. My application uses only a small subset of GTK+ features, so I could remove the file chooser, font chooser, assistant, print support, spin button, recent documents chooser, spinner, etc. Gtk+'s .dll is not that big actually, most of the size of it comes from the ammount of dependencies it has and the translation files. -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
2010/6/14 Sam Thursfield sss...@gmail.com: A more socially-minded approach would be to work on the problem of sharing a GTK+ runtime between all apps on a system. It's perhaps not an easy problem, due different requirements in versions and specific libraries, but it's a more long-term solution to the problem of GTK+'s big runtime than for each app using GTK+ on Windows to build and distribute their own incompatible versions. That is just not how you ship stuff on Windows unfortunately, there is no apt/zypper/yum like thing for Windows (though MS seems to be working on that apparently). tml and myself went through this problem again and again, even if GTK+'s API is stable, guaranteeing GTK+'s ABI on Windows is just impossible for several reasons, a common GTK+ runtime is just not the way to go. Easing the bundling process of Gtk+ into a windows app/installer, and reducing the amount of dependencies is the way to go. Sam ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GApplication and GtkApplication oddness
2010/6/9 Richard Hughes hughsi...@gmail.com: With GApplication we have: application = g_application_new_and_register (org.gnome.ColorManager.Prefs, argc, argv); and with GtkApplication we have: application = gtk_application_new (argc, argv, org.gnome.ColorManager.Prefs); It does seem slightly odd that the former has the appid first, and the latter has it last. I'm not sure it matters much, but I figured feedback might be useful. I do think it matters a lot, there should be consistency between calls, good catch. Richard. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GApplication and GtkApplication oddness
2010/6/10 Richard Hughes hughsi...@gmail.com: On 10 June 2010 10:34, Alberto Ruiz ar...@gnome.org wrote: I do think it matters a lot, there should be consistency between calls, good catch. For what it's worth, I prefer the glib style, so the app-id goes first. I guess it makes sense since a lot of people are going to go for NULL, NULL in argv, argc. I can even see those being an optional argument in the python bindings for example, whereas the app id is mandatory I would assume. Richard. -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ irc team meeting
2010/3/17 Emmanuele Bassi eba...@gmail.com: hi everyone; it's been a while since the last one, so let's get the ball rolling once again. next tuesday I'll be offline, until the 25th included, but it would still be good to have an irc meeting; the 26th is friday so I can understand if people will just laugh at a proposal for holding the meeting at that date. if everyone is okay with tuesday 23rd at 20:00 UTC it's fine by me - I'll still try to attend, but I cannot promise anything. I'm in :-) proposals for alternative dates and times are accepted. the proposed agenda for the meeting is: • CarlosGarnacho: MPX awesomeness GTK+/MPX • CarlosGarnacho: GtkStyle (bug #541136) and GtkRcStyle (bug #540392) sealings • JavierJardon: Discuss possible solutions for GtkTextView-need_im_reset accessor (Bug #163251) • JavierJardon: Session Management support (GnomeClient replacement), is really necessary? See Bug #79285 comment #30) • EmmanueleBassi: Application class in GIO/GTK+; API, Shell and application requirements - see GTK+/ApplicationClass • Miscellaneous see also: http://live.gnome.org/GTK+/Meetings the proposed time and date for various timezones is available at: http://www.timeanddate.com/worldclock/fixedtime.html?day=23month=3year=2010hour=20min=0sec=0p1=0 ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook scrolling usability
2010/3/11 Sandy Armstrong sanfordarmstr...@gmail.com: On Wed, Mar 10, 2010 at 4:20 PM, Luca Ferretti elle@libero.it wrote: Il giorno mer, 10/03/2010 alle 16.50 -0600, Cody Russell ha scritto: 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'm a big fan of this feature, it allows me to quickly switch between tabs without move the pointer. It's really useful when I don't know/remember which tab I actually need or want to activate. It helps you to be more streamlined, so I can't understand why it should be an issue for novice users... I also happen to be a fan of this feature. I use it in my web browser of choice, in gnome-terminal, in gedit, and similar applications. I don't find it as handy in preferences dialogs. If there ends up being a bug report about this, please share the bug number. And hopefully we can get some usability nerds involved in this decision. I agree with Sandy here, I would leave this decision up to the usability guys. Sandy ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook scrolling usability
2010/3/11 Vinicius Depizzol vdepiz...@gmail.com: On Thu, Mar 11, 2010 at 10:01, Carlos Garnacho carl...@gnome.org wrote: I may understand not all notebooks need this feature. Perhaps we could have a MDI mode in GtkNotebook, so features such as mouse wheel scrolling and tab switching on alt+number are effective on these? (The latter isn't done in GTK+ itself yet, but is featured by most multitabbed apps) A MDI mode is a good idea. GtkNotebook widget is used both for tabbed document interfaces and for dialogs, which are quite different situations. And while they have the same visual appearance[1], the tabs don't represent the same structure of content. [1] MDI mode in GtkNotebook could even remove visually its border. Since in these cases the widgets don't have padding (as opposite from dialogs), the GtkNotebook border is always duplicated from some other border (like the window one). This is easily visible in Epiphany when there are no tabs in the window and when you open a new tab. Thank you. Actually, this reminds me of an issue I had while trying to fix tabs in the Mac OS X/Quartz engine. Basically, on MDI, the Mac preference tab mode, is pretty weird, that's why Safari and Firefox have their own drawn tabs instead of the typical tabs in a preference dialog. If we had a setting to let a tab have MDI mode, that could solve the problem from the engine standpoint I think. -- Vinicius Depizzol vdepiz...@gmail.com http://vinicius.depizzol.com.br ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook scrolling usability
Actually, this reminds me of an issue I had while trying to fix tabs in the Mac OS X/Quartz engine. Basically, on MDI, the Mac preference tab mode, is pretty weird, that's why Safari and Firefox have their own drawn tabs instead of the typical tabs in a preference dialog. If we had a setting to let a tab have MDI mode, that could solve the problem from the engine standpoint I think. Now that I think about it, I think the notebook needs a review from a wider perspective. We are trying to make this class one-size-fits-all-cases. We already discussed about simplifying this widget a bit (we already deprecated the tab-pack child prop for example), other things should be simplified as well (I just filed bug #612567 about properties that should be). I think that preference and MDI tabs are quite different, I think we should have an DocumentsNotebook and PreferencesNotebook classes using GtkNotebook as a base class, both classes can then provide sane defaults and additional properties for both use cases (like close button on MDI tabs which makes no sense on preference tabs) This would also allow themes and engines to manage both situations in a saner way instead of trying to collect all properties and figuring out what the usecase is. Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook scrolling usability
2010/3/11 Johannes Schmid j...@jsschmid.de: Hi! Am Donnerstag, den 11.03.2010, 14:20 + schrieb Alberto Ruiz: Now that I think about it, I think the notebook needs a review from a wider perspective. We are trying to make this class one-size-fits-all-cases. We already discussed about simplifying this widget a bit (we already deprecated the tab-pack child prop for example), other things should be simplified as well (I just filed bug #612567 about properties that should be). I think that preference and MDI tabs are quite different, I think we should have an DocumentsNotebook and PreferencesNotebook classes using GtkNotebook as a base class, both classes can then provide sane defaults and additional properties for both use cases (like close button on MDI tabs which makes no sense on preference tabs) I am not sure if we need the two classes but I would love to see someone step up and clean the GtkNotebook code in general for 3.0. Having worked on a couple of bugs/features for GtkNotebook I must say that it has probably the most crappy code of all Gtk+ widgets. That doesn't blame any of the authors but this code has grown incrementally and became worse as nobody had a clean concept. And most of the code was already in Gtk+ 1.2. This is part of the story of my proposal, it's not better only from an API usability point of view, but it also prevents from having a single class where all the crack gets added, making the whole situation a little more sustainable long term wise. Regards, Johannes -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Usability] GTK+ at the UX Hackfest
2010/3/8 Matthew Barnes mbar...@redhat.com: It would also be useful in Evolution for opening attachments... Are projects like Firefox or Thunar willing to use gmenu or gnome-desktop as a dependency? I remember talking about this issue with Michael Ventnor from mozilla and he said that if such a widget was there in Gtk+ they would use it. Matthew Barnes ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Creating GObject/GTK bindings for language
2010/2/26 Tristin Celestin tristin_celes...@yahoo.com: I want to be able to use GObject and GObject based libraries from an object oriented scripting language with no bindings for GObject and GObject based libraries currently. Which library do you want to bind, your own? Which scripting language are you targetting at? How does one go about creating GObject bindings for another language? I've read the GObject-Introspection pages at gnome.org and looked at the PyGobject binding, but I still don't have a clear idea of where to start. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 2.90 branch
2009/9/30 Emmanuele Bassi eba...@gmail.com: sure. I asked around on #gtk+ after GUADEC for the best day/time to maximize attendance - the default being on Tuesday at 20:00 UTC. if anyone has issues with the day/time then feel free to contact me either on gtk-devel-list, in private or on IRC. otherwise, we can have a IRC meeting next Tuesday (October 6th); this should give people enough time to schedule stuff around. :-) +1 ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Deprecate tab-pack child property in notebook for 2.18
2009/8/27 Kristian Rietveld k...@gtk.org: On Mon, Aug 24, 2009 at 3:34 PM, Alberto Ruizar...@gnome.org wrote: So my proposal is to deprecate this child property for the 2.x series, so that we can get rid of it by 3.0, (meaning 2.18?). This would allow a long overdue cleanup in the notebook codebase and make it more manageable to include other features (tab sliding animations ala Google Chrome as an example?) Any thoughts? Am I talking crack here? Matthias? Kris? :-) Okay I consulted Carlos on this one, because I thought the property was operating on the contents of the tab, but apparently it is about the tab itself. I fully agree that this is an interesting feature ;) I also see how this complicates the code by at least a single order of magnitude. When removing, the functions that Christian pointed at should be taken into account. (Maybe deprecate those two functions and have separate accessors for the remaining tab-fill and tab-expand properties?). That sounds like a plan to me, might spend some time on that after my exams (you're not the only one with college duties ;-), that won't be before the 15th though. What I am still wondering about is the history of this feature. Why was it included in the first place? Carlos says he thinks this was included because of some effort to make all containers obey the same child properties. I don't have any background on the story of the feature, but TBH and IMHO, IT IS WRONG! ;-) If anything, PACK_END should just set the tab to be the last in the order, but I don't think pack start/end makes any sense here. I mean, unless I'm missing something and this deprecation breaks something really badly, which I'm 99% is not the case, we should kill this nonsense :-) -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Proposal: Deprecate tab-pack child property in notebook for 2.18
Hello everyone, as you may know, the notebook implementation is a bit of a nightmare, most of its problems comes from the fact that it allows packstart/end on its notebook tabs. I don't think I've ever seen this being used in any Gtk+ app (or in any other toolkit fwiw), and for those out there using it, they deserve no mercy. So my proposal is to deprecate this child property for the 2.x series, so that we can get rid of it by 3.0, (meaning 2.18?). This would allow a long overdue cleanup in the notebook codebase and make it more manageable to include other features (tab sliding animations ala Google Chrome as an example?) Any thoughts? Am I talking crack here? Matthias? Kris? :-) -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notes and thoughts on the GTK+ meeting at GUADEC
2009/8/19 Cody Russell brats...@gnome.org: On Tue, 2009-08-18 at 15:27 -0700, Christian Hergert wrote: One of the items I haven't seen discussed is input validation. Web frameworks such as Rails and Django spent a great deal of time making these easy to work with and I think that it should be considered for gtk+ 3.0. Isn't this something to be considered after the 3.0 release? I can't think of any reason not to do it during the after 3.0 lifecycle. I only took a really brief peek, but this is something I've thought about in the past as well inspired somewhat by the validators that Medsphere had (I can try to dig up the code if you're interested in it, but yours seems to be pretty similar in some ways already). I'll play around with it and look at it in more detail soon. The most obvious thing I see just from peeking at the API is that true/false is not enough information about the result of a validation.. you probably need some way for widgets to be able to provide custom error messages when they fail. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notes and thoughts on the GTK+ meeting at GUADEC
2009/8/19 Kristian Rietveld k...@gtk.org: On Wed, Aug 19, 2009 at 11:13 AM, Alberto Ruizar...@gnome.org wrote: 2009/8/19 Cody Russell brats...@gnome.org: On Tue, 2009-08-18 at 15:27 -0700, Christian Hergert wrote: One of the items I haven't seen discussed is input validation. Web frameworks such as Rails and Django spent a great deal of time making these easy to work with and I think that it should be considered for gtk+ 3.0. Isn't this something to be considered after the 3.0 release? I can't think of any reason not to do it during the after 3.0 lifecycle. If it's done on time, I don't see why it cannot make 3.0. Otherwise I am sure it can be accepted in 3.2 for example. Yeah, that makes sense, if someone is willing to spend some time working on this, it'll be awesome to have! -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notes and thoughts on the GTK+ meeting at GUADEC
2009/8/19 Kristian Rietveld k...@gtk.org: On Fri, Aug 14, 2009 at 1:40 PM, Alberto Ruizar...@gnome.org wrote: 2009/8/14 Kristian Rietveld k...@gtk.org: As for theming, I've been discussing a bit with Thomas, Carlos and Cody. We have reached some sort of consensus that a backwards compatible path is possible adding a second vtable for engines, checking the vtable size and working out a structured way to poke the scene graph representation. However, we need time to try these things out. Thomas pointed out that working on a separate theming library makes a lot of sense as it would allow reaching a nice API and it would help the special purpose GObject baed toolkits around to have proper theming as well (say Nbtk, Glitter...). So I think that we've reached the conclusion that theming shouldn't get in the way of the current 3.0 plans, as we don't have time to deprecate GtkStyle and introduce something new all at once (eventhough, we all would have loved to make it). Great to know that progress is being made here. Trying things out definitely sounds like a good idea. Even though we are now not planning to deprecate GtkStyle in 3.0, we should have an idea whether just sealing it will provide enough flexibility to migrate to something new at a later stage. I think one of the larger problems has been the hard-coded array sizes of the arrays containing GdkColors and GdkGCs (but I am not at all an expert on GtkStyle and theming), and this limitation should disappear in a properly written accessor function. Are there more pitfalls that can hold us off from a successful migration in the future? From my point of view, sealing everything theming related, deleting all the deprecated style methods would be a great move. Also, with csw, we could move to a assumed background is already painted policy for elements, this should improve the third party usage of element drawing where they have to do dirty hacks to avoid corners being painted for rounded elements (like firefox entries and buttons). But again, this doesn't really stop anything 3.0 Sealing all GtkStyle and other theming related object members will definitively help to prepare a backwards compatible solution, a lot. There's the issue of CSS though. Would it be acceptable to deprecate gtkrc's in the middle of the 3.0 cycle in favor of CSS theming files? This is an area where I'm pretty much blind, prolly Robert Staudinger has a better picture than me here, Robert? Can current gtkrc's and CSS theming files co-exist? I'm not sure who would be able to answer this question, but I guess that at some point they should coexist in some sort of fallback way (if !css = gtkrc), actually the presence of the css would be a good way to figure out which engine should be loaded first. -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notes and thoughts on the GTK+ meeting at GUADEC
2009/8/14 Kristian Rietveld k...@gtk.org: Hi All, A different way to start working on the new features is to decide on a feature set first, research the features and (if required) make required changes *before* an ABI frozen GTK+ 3.0 is put out. This brings up the next question: what features to research first? For this, I think we need to talk with our prime users: GNOME, GIMP, Mono/MonoDevelop, XFCE, etc, etc (this list is of course fully up for discussion). Make them aware of the existence of the roadmap and ask them what features are most important to them and which they feel are missing. Talk with the most active people involved in theming and art (there really is much going on in there right now) to come to consensus on a feature set with regards to theming; this is important because it will tell us what GtkStyle should be migrated to. Also look at outstanding patches adding new features in Bugzilla. This is an information gathering phase that can be turned into a GtkTask[4]. If people agree with this approach, we can turn this into a more formal and clear description of the work. First things first, thanks a lot Kris for taking the bullet and kickstarting this discussion, congrats for finishing college and I'm really excited to have you back ;-) As for theming, I've been discussing a bit with Thomas, Carlos and Cody. We have reached some sort of consensus that a backwards compatible path is possible adding a second vtable for engines, checking the vtable size and working out a structured way to poke the scene graph representation. However, we need time to try these things out. Thomas pointed out that working on a separate theming library makes a lot of sense as it would allow reaching a nice API and it would help the special purpose GObject baed toolkits around to have proper theming as well (say Nbtk, Glitter...). So I think that we've reached the conclusion that theming shouldn't get in the way of the current 3.0 plans, as we don't have time to deprecate GtkStyle and introduce something new all at once (eventhough, we all would have loved to make it). There's the issue of CSS though. Would it be acceptable to deprecate gtkrc's in the middle of the 3.0 cycle in favor of CSS theming files? This is an area where I'm pretty much blind, prolly Robert Staudinger has a better picture than me here, Robert? Now, what I'd love to see is having IRC meetings back, ebassi and myself talked roughly about it on IRC, seems that mclasen has a toughest schedule these days. Anyone up to figure out hours/date to have a 3.0 kickstart meeting and do some rock and roll? As I said, thanks a lot for the heads up Kris! -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Quartz DnD patch review approval sought
2009/8/12 Kristian Rietveld k...@gtk.org: Hi Paul and John, On Tue, Aug 11, 2009 at 7:17 PM, John Rallsjra...@ceridwen.us wrote: http://bugzilla.gnome.org/show_bug.cgi?id=588449 I'd appreciate some more review and possible approval of this patch. It would remove the last substantive item in the patch that is necessary to get Ardour to run on GTK/Quartz, and would presumably help other applications similarly. And while whoever is at it, could he also look through the other GTK+ Mac tickets and close the ones that are clearly obsolete (like the two can't compile bugs from 2.13)? I recently got a recent version of GTK+ building again on my Mac. I am still on Tiger and it needs some more fixes before it cleanly builds GTK+ again, I intend to look into this soon. When that is done, I will certainly try to find time to go through the pending Mac bugs and see what I can do. Please understand that I currently am no where near as experienced hacking on the Mac port as Richard is. Also I've got a good bunch of other stuff on my plate as well, so I cannot promise time frames/deadlines at this point ... I recently bought a Leopard license to start playing out again, once I have broadband at home I'll setup a full jhbuild environment there so expect a little help from my side eventually, although I've been only playing with theming bits so far, nothing in the backend. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
2009/8/5 Robert Staudinger robert.staudin...@gmail.com: On Tue, Aug 4, 2009 at 1:08 AM, Tristan Van Berkomt...@gnome.org wrote: [...] I think half of that complexity is certainly needed, and the other half can be reliably introspected. For instance: a.) I think its necessary for a customized composite widget author to be able to mark a vbox as an itemized list, which directly translates to: its wrong to assume a GtkBox contains an itemized list of widgets, and its bad design to write code that tries to guess that information by casing the types in the hierarchy. b.) I think its not important to specifically have the GtkBox mark the first or last child as first or left or top, if the positional information needed to layout the contents of a GtkBox can be introspected with consistent results. Also, Christian suggested that we expose read-only child properties specifically for use in the theme engine, this would work but IMO would be equivalent to assigning some theme tag data to the child widgets of a container, i.e. it would be code written in the GtkContainer implementation dictating how the theme should handle the child widgets. Either way would work well, also, it would be possible to instead introspect the packing at runtime reliably by listing the children of a container and comparing their coordinates to eachother relative to the parent container, thus deriving virtual row/column information. The problems I see with the current gtkrc/GtkStyle is only the guesswork thats done on the classes directly, this causes apps to be written more rigidly to cooperate with the theme and I also think GTK+ application layouts can potentially be pretty complex and definitely have needs that span beyond every GtkEntry looks like this. To fix these limitations I think its necessary to add a level of abstraction across the board, that allows the application to define what is the style to be used for a widget or container and also allows the theme to define classes that suit an idea from a list of stock items that would be required to implement the base GTK+ theme. In an ideal world, only a composite/specialized widget would have some theme data defined, and a GtkButton, GtkEntry or GtkComboBox would always come out reliably naked and unthemed - unless a style has been explicitly set for that widget, or unless you place the GtkButton in an itemized list or a dialog action area, the effect of adding a GtkEntry to a spreadsheet area might be different than the effect of setting a GtkEntry to be of the style urlbar or password. It seems we are looking at the issues from a different angle. I think all gtk should do is expose a DOM that the future CSS subsystem can match against. Then there could be a gnome-hig.css that when loaded sets HIG compliant paddings and spacing like the standard group indent you mentioned. I sort of agree here, I don't think we should support the full DOM API though, just enough for CSS to do its job. On the other hand, anything we do to represent an abstract scenegraph and poke properties could potentially be shared by the accessibility bridge (gail) which would be a big win IMHO. That would avoid putting semantics into gtk proper that are not applicable to all platforms (desktop, embedded, whatever) or might go stale in the future. - Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ 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/8/3 Steve Frécinaux nudr...@gmail.com: Bastien Nocera wrote: I could think of at least 5 types of compressions that would be useful to have without having to use a command-line tool to decompress: - gzip for anything and everything that can come from a web server (in my case, iTunes Music Store playlist parsing, or more widely, GOffice file formats) - zip for OpenOffice.org documents and Comic Books (evince) - 7zip/LZMA/Xz formats for Comic Books - Rar for the same as above Aren't there two classes of file types there ? Compression vs Archiving I mean, zip, 7z, and rar are archiving format who store files in a compressed fashion (kind of like a tar of gzipped files) so rather than just having a stream you need to have some support for archives there, and not just the compression part like gzip or bzip2... I wonder if we should split this in two approaches, having gvfs modules for archives (compressed or not) and gio-loaders for compression only formats (gzip and bzip2). -- Un saludo, Alberto Ruiz ___ 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 Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com:
2009/7/31 Jody Goldberg j...@gnome.org:
On Fri, Jul 31, 2009 at 02:48:47PM +0200, Mikkel Kamstrup Erlandsen wrote:
Hi,
I've been eye balling the GIO docs for a while without finding
in-/output for gzip compression... So if I missed it stop me now :-)
From the looks of it, it should be straight forward to write
GZip{In,Out}putStream classes based on zlib[1]. If I write these
classes would a zlib dep. be OK for GIO? It is pretty ubiquitous as
far as I can tell (and it is already a depency of Gtk+)... And I am
not really all that keen on writing my own gzip/DEFLATE implementation
(to say the least).
Another thing is the naming. Since this is not about supporting the
Zip archive format (but that would be nice too) the name GZip*Stream
might be bad. On the other hand i abhor the ALLCAPS GZIPInputStream
used in fx. Java. What about GGZip*Stream - eeek!?
libgsf has all these, along with a gio wrapper.
I assume you mean:
http://projects.gnome.org/libgsf/gsf-Compression.html? I could not
find the GIO wrapper in the documentation (assuming that it is
unreleased yet?). Anyways - my question is really if this
functionality should not be in GLib/GIO?
I sort of like the proposal.
Cairo and libpng depends on zlib and there's no Win32 API to replace
it so the implementation would be fully cross platform it's very basic
functionality IMHO and having it in a GIO wrapper would be awesome.
I'd love to see BZip2/7zip/Tar/rar/... wrappers somewhere else in the
platform though (and kill most of the file-roller codebase for that
matter).
Only downside from my point of view is that in Windows this would mean
yet another .dll to distribute.
Adding a native GIO impl. would of course be looking heavily towards
what already exists in Gsf.
--
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Un saludo,
Alberto Ruiz
___
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. Tarricone bj...@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.
And expand the list of glib dependencies to the infinite?
I don't think I like such an idea at this level of the API.
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Un saludo,
Alberto Ruiz
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
2009/7/30 Christian Dywan christ...@lanedo.com: Am Tue, 28 Jul 2009 08:45:26 +0200 schrieb Robert Staudinger robert.staudin...@gmail.com: On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarickk...@xph.us wrote: [...] The margin property in gtk is not implemented like you assume above. Also does GtkContainer not expose information about child widget positions like you suggest using :first-child and friends. Work on those limitations would break the way for more a more comprehensive mapping of css onto gtk. Okay. I only meant that example to suggest what a theme could do in principle, even if it uses features that don't exist yet. Would you accept a patch with work toward those things, such as margin or first-child? If there way a way to get the position of a child in a GtkContainer (thus allowing for :first-child and other positional pseudo classes to be implemented) that would make quite a difference in what you can do with the css engine. I'm not in the position to make the call on gtk patches though. You are probably aware that gtk_container_get_children () does give yo the positions of children. Assuming that the lack of guarantees about order of widgets in a container is the actual problem, maybe this can be reconsidered. There was a bug I can't find right now suggesting a policy for this containers would be recommended to follow. That sort of works for a widget instance, but doesn't work generically when you're painting a pseudoelement, for example, a notebook tab. I'm all ears if someone suggests a sane fix for this. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ Font Dialog improvements
Hello there, I did some work[0][1] time ago and I actually wanted to talk about improvements on the dialog with Behdad during Guadec, although the schedule went against us. I want to point out that the most common usecase for the font selection is often dismissed. People just want to look for a font that would look good for a particular piece of text. I think that the current dialog fails to maximize the previewing capabilities in detriment of showing all the options available in a textual way. To give some examples of the problems: a) When browsing fonts, the first thing the user would set is the typeface, and the size. However the size is the only setting that is kept after changing to another font, the typeface goes always back to regular, which is VERY annoying. b) Most times, the user won't know which particular value does he want for the size. This is most times a guess work, this guessing implies clicking on every number, and eventually scrolling up or down until getting to the point the user is happy about it. This is VERY annoying too! c) Same problem as the size applies to the Typeface. d) When a user browse families, ideally, a preview would be shown in the family list, behind the family name. (I know this is an issue performance wise, and this is exactly the point that I wanted to discuss with Behdad) Some suggestions that come to my mind to adress some of these issues: * Removing the size list. It is not useful as it is and wastes loads of space. The numbers themselves are not that meaningful at a fist glance. Most times you just want to check more or less what's the right size. A combination of slider+spinbox would do a better job usability wise. * Merge the typeface and the preview, showing previews of every typeface. (Pending issue with this approach would be solving the preview text editing). * Remembering the typeface selected after changing from one family to another. * Family class combobox to be a search box with filtering (a la thunderbird), the treeview textfilter is not the most discoverable thing and it's a click away from the filter box. * Showing a small preview of the text on the family list as inkscape does in its toolbar when editting text on the canvas. [0] http://aruiz.typepad.com/siliconisland/2008/08/font-selection.html [1] http://aruiz.typepad.com/siliconisland/2008/08/font-selectio-1.html 2009/7/20 Henrique Carvalho Alves hcarvalhoal...@gmail.com: On Sun, Jul 19, 2009 at 1:55 AM, Henrique Carvalho Alves hcarvalhoal...@gmail.com wrote: There was discussion on this some time ago, and the discussion got lost. I'm trying to raise interest on this issue again. I did a mockup for a new gtk+ font chooser, as I find the current one lacking from usability aspects, and wanted to gather some feedback. If there's any interest, please read the rationale at my blog: http://hcalves.tumblr.com/post/144502395/one-th ofing-i-dislike-on-gtk-its-the-current-font The mockup is functional and implemented in Python + Glade. It's available at my Launchpad: https://code.launchpad.net/~hcarvalhoalves/+junk/gtkfontdialog I would appreciate feedback from user and developer viewpoints, and further discussion for improving the dialog. Just to ping the thread - I committed some changes today, now dialog behavior and features are matching my original intentions regarding the UI and features, with one issue left: the use of an appropriate, internationalized text for preview. The issue is better discussed on the blog post. I wanted feedback from someone more experienced in the Gtk+ stack and C, willing to implement this mockup, maybe a branch or patch against GtkFontSelection(Dialog), and leveraging pango_language_get_sample_string() for providing a better preview text. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A tale of waiting
2009/6/23 Bastien Nocera had...@hadess.net: On Tue, 2009-06-23 at 22:16 +0200, Benjamin Otte wrote: I have been on a quest to improve performance of the file chooser lately. This post is about this process: what I measured, what I learned and what I patched. snip * Getting the mime type Getting the mime type for a file requires opening the file and checking the first bytes against the known patterns for files. Both operations take time. The mime type also is usually not required. It will only open the file if the suffix of the file can't be used, please read the shared-mime-info spec. Yes, I've been looking into this code recently, there's a fast mode, and it's only when the fast mode happens to be ambiguous, that a short stream of the file is taken for sniffing. snip * Fix the usage of a filter on the mime type. Currently we don't query the mime type (it requires file sniffing after all), so we never get matches. As above. In majority of cases it should be a string match. snip And now the obvious question: Should I just merge it to master when I'm done with the regressions? Personally, I'd rather see the changes merged incrementally, rather than a wholesale rewrite going in. Makes it much easier to pinpoint what broke the file chooser (as is likely to happen, it's not like software is ever bug-free). Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client side windows - request for testing and reviewing
2009/6/17 Alexander Larsson al...@redhat.com: The client side window branch is now feature complete on X11, and includes API to do offscreen window embedding (with patches for clutter-gtk availible to test this). Today I merged the latest master into the branch to make it easy for people to test it (its got the new so version). I fixed the last known (to me) bug yesterday (an obscure WM interaction issue on loading the saved session), and am running this as my default Gtk+ without issues. The win32 branch is getting some work done by Cody Russell, and the Quartz backend used to work fine but requires some minor API change updates (hopefully Richard can do this soon, CC:ed). It would be very nice if we could merge this soon. However, to do that we need more testing and people to look at the code. As things stand right now I've gotten essentially zero feedback. I don't know of anyone except the two backend porters who have built or looked at the code really. So, please, please, please, test this code. We need people who run uncommon apps to test it, and we need people to run it on apps they know really well so we can find minor changes in behaviour. Alex, count on me to test it during next week :-) Also, anyone who knows gdk or have an interest in this, please take a look at the code and give feedback. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk/CSS update
2009/6/9 Robert Staudinger robert.staudin...@gmail.com: Hello, seems everyone went back to their cubicles and put the heads down after the Dublin theming event, so here's a brief update for the CSS part. Yes, sort of true, however, I know myself that Carlos has made some progress with the StyleContext branch, I will let him give some updats on his front. Libccss [1] --- Gtk-CSS-Engine [3] -- CSS Theming --- Nice stuff Robert! Thanks for the heads up. Carlos it would be nice if you put your stuff upstream so that we can all start integrating things together and having a public branch with all the pieces. [1] http://people.freedesktop.org/~robsta/libccss/ [2] http://webkit.org/specs/CSSVisualEffects/CSSAnimation.html [3] http://www.gnome.org/~robsta/gtk-css-engine/ [4] http://bazaar.launchpad.net/%7Ecascaders/ubuntu-artwork/css_themes/revision/29/pioneer.svg Best, Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Hackfest around Boston Summit
2009/5/20 Cody Russell brats...@gnome.org: I'll definitely attend, and I'd like to join a hackfest if one happens. I think I can arrange it to attend as long as enough theming or win32 people are around :-) On Tue, May 19, 2009 at 11:06 PM, Behdad Esfahbod besfa...@redhat.com wrote: Hi everyone, Since the last attempt to organize a GTK+ hackfest failed and not many GTK+ people seems to be going to GUADEC, I wonder whether there's interest to organize a hackfest around Boston Summit. That would make mclasen, ssp, and davidz readily available. What do the rest of the team think? behdad ___ 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 http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
2009/4/8 Ryan Lortie de...@desrt.ca: Hello Everyone! I'm proposing GVariant for inclusion in glib this cycle. Nice! At last! All hail to desrt :-D I've created a 'gvariant' branch of glib and pushed it to the official repository. For those who don't know what GVariant is, please see the announcement email here: http://mail.gnome.org/archives/gnome-announce-list/2009-March/msg00103.html GVariant is currently used by GBus and dconf/GSettings. It has general usefulness to anyone who wants to do any of the following things: - send structured data over network sockets - save structured data to disk - efficiently deserialise this data (particularly out of mmaped regions; only as much is faulted in as is needed; this makes it great for icon/schema/font/etc type cache files) - do anything with dbus, really. The type system, of course, is that of DBus. I love your feedback. Please give it all to me. Cheers ps: sorry for the delay :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: No GTK+ Hackfest this year
2009/3/25 Behdad Esfahbod beh...@behdad.org: On 03/25/2009 06:56 PM, Andreas Nilsson wrote: Behdad Esfahbod wrote: Hi, Some may have heard that I've been planning the Bolzano GTK+ Hackfest. Well, given the economy, we are canceling that plan for now. The global economy or the GNOME Foundations economy? Well, the two are not really separate. Last year we raised over 80% of the GTK+ hackfest expenses from the advisory board members, and many companies paid for airfare of their employees going to the hackfest. This year we failed to do the former, and I expect the latter also being an issue for many of the companies. Behdad, do we have an estimate of how much money the former one costed (including accomodation, and travel expenses)? It would be interesting to have that information at hand to figure out how much money should be raised so that the Foundation could afford it. And the foundation budget is also tight this year. We don't want to dip into our cash reserves too much. Stormy and J5 are working on a financial report and budget for the year which will better explain the foundation numbers. behdad - Andreas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ 3.0 Theming API Hackfest Minutes
2009/3/12 Cody Russell brats...@gnome.org: On Tue, Feb 24, 2009 at 12:30 AM, Alberto Ruiz ar...@gnome.org wrote: * All drawing funcitions to use a cario context and hide GtkWidget and GdkWindow (Strong request from 3rd party toolkits) After thinking some more about this, I'm not convinced that getting rid of the GtkWidget* pointer is a good idea. We should not pass a GdkWindow* handle, and we should pass the cairo context.. but if we don't pass the GtkWidget* pointer then we will potentially lose a lot of things that can be exposed to a theme engine won't we? For example, what if you want to know what is the type of the parent container? We can dump it into the StyleContext under the parent key. But what if we want to know the grandparent container? What if we want to know next/previous widget in the parent container? It's hard to forsee what's useful. On the other hand, what if the widget is NULL? I think the point of removing the GtkWidget* pointer was so someone like Firefox can pass all the useful information through the style context without needing to have an instance of a widget. But I don't think we should bend over backwards to suit their interests if it means restricting our own possibilities and cutting out obvious use cases. Hiding the widget pointer is not only something that we are doing to please the third party toolkits. We are doing it because it is easy to abuse implementation details of the widget that makes widget maintainers life harder. The widget implementation becomes public data that cannot change without breaking engines making use of it. The idea is that CSS selectors allows us to represent the widget hierarchy, and we use this Dom to get rid of the widget pointer. Any thoughts? / Cody -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ 3.0 Theming API Hackfest Minutes
2009/3/2 Behdad Esfahbod beh...@behdad.org: Alberto Ruiz wrote: * All drawing funcitions to use a cario context and hide GtkWidget and GdkWindow (Strong request from 3rd party toolkits) When we discussed this before, I among others suggested that this is wrong as it hardcodes cairo as the only supported drawing system in the API. For example, one wouldn't be able to use OpenGL for drawing anymore. Well, you can always get the native device of the surface. This works for Windows and Mac native drawing APIs. You can then create an OpenGL context out that (someone correct me if I'm wrong here). A bit tricky, we might add facilities for that, but most engines are going to use cairo anyway. Instead I suggest an opaque object be passed to the draw function, then have constructors for various drawing APIs. Say: cairo_t * gtk_themeable_window_create_cairo (GtkThemeableWindow *w); behdad -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gtk+ 3.0 Theming API Hackfest Minutes
Hello everyone, at last, the hackfest is done, and that doesn't mean that we don't have a whole lot of work ahead of us. But at least we have a team of people trying to push an idea forward. This is a rough summary of the agreements/plans we did during the hackfest: * Get rid of style properties and replace them with global padding (on GtkBin) * Get rid of GtkRCStyle and GtkStyle (Cody to work on a smooth migration path) * An extensible GtkStyle replecament that allows to get rid of the detail string (Carlos Garnacho's GtkStyleContext). * All drawing funcitions to use a cario context and hide GtkWidget and GdkWindow (Strong request from 3rd party toolkits) * Use a CSS syntax for theme files (work with Jens to find a way to make Qt and Gtk+ files somewhat compatible in the future if possible) * Use CSS matching rules to apply to the scene graph (hierarchy, siblings...) * Deprecate (polygon, diamond, tab, shadow primitives). * New GtkStateType (bit field that allows multiple states at the same time). * Have a comprehensive list of the widget parts (pseudo elements) available in the toolkit. (Right now implicit in hierarchy+detail string). * Try to keep the primitives as small as possible (draw_part + special cases like draw_text_layout...) * Themed animation support (garnacho's timeline+stylecontext) * Hit detection (allow engines to push the last shape drawn to the style context, use of the transformation matrix to support layout animations to detect hits). * Basic CSS support in the default engine, full CSS support in a full featured CSS engine (Robert Staudinger work on libcroco/libccss). * ARGB by default * Port the 2.x default engine to use cairo natively. Yes, loads of crazy stuff, but we think we can do it, we would appreciate any feedback. Some branches where people are trying out stuff: * git://github.com/aruiz/gtk-roles-and-siblings.git (hit detection support based on garnacho's style-context, checkout the style-context branch) * git://github.com/garnacho/gtk-roles-and-siblings.git (garnacho's style-context and animation support, checkout the style-context branch) * git://github.com/thos/gtk-cairo-engines.git (2.x default engine port to cairo) * http://bzr-playground.gnome.org/~robsta/libccss-selection-engine/ (improvements towards support needed features of CSS) -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ 3.0 Theming API Hackfest Minutes
2009/2/23 Morten Welinder mort...@gnome.org: Were there any discussions on fault separation between the application and the theme engine? The current state of affairs is that theme engines have a long record of crashing applications or even changing their functionality. When that happens, the user blames the application and, sometimes, files bugs against it. Application developers are left with bugs that cannot be reproduced. Notice that all that is going to be accessible now is the cairo context, no access to widgets, gdk window, whatsoever. So things are going to improve a lot here. We can't save applications from a SegFault from an engine. But with our current design behavior cannot be changed anymore. Morten -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: minutes of the gtk+ team meeting - 2009-01-20
2009/2/19 Luc Pionchon pionchon@gmail.com: 2009/2/18 Alberto Ruiz ar...@gnome.org: The idea es that Gtk+ is actually something that enables really cool things, but we don't empower that idea from the website. The other point is that bindings seems like second class citizens whereas it's actually quite the opposite. I think that a lot of the confusion out there about Gtk+ being written in C is an issue, is that the documentation that you have in the webpage is all about C. Which is something that most people shouldn't bother about. The other point is that we need other sort of documentation, the tutorial is nothing but a widget-by-widget manual, not something that you want to use to learn how to build a useful Gtk+/GNOME app, the worst thing here is that this is the reference document used by some binding documentation (pygtk for example) so you spread a C-like api that doesn't really encourage subclassing and good practices for the sake of simplicity (useful from the C point of view). In this regard Getting started with gtkmm looks a much better approach to me, but since it is under the gtkmm.org umbrella, it doesn't get that much attention. Also, we need screencasts to create really basic apps with Gtkmm or PyGTK for example, so that people can really get into Gtk+ without even to follow a text document and start playing. This is how Rails got millions of developers really excited and faded Django out of the picture for some time, if you go to the RoR page, you can get a clue on how to start really easily and figure out what kind of things you can do. At the moment the Gtk+ webpage, although much better than the previous one, is all a lot of some boring text that doesn't really shows what Gtk+ can do and doesn't encourage anyone to try it unless you already know what it is. I plan to work on some other mockups of the website for other sections and I would like to get feedback from you guys. The mockup looks great, and the reasoning makes full sense to me! At the GNOME level, the part of the GNOME dev platform label, seems very good. Is it a Gnome initiative? Is just an idea, so that people understand easily that you have more components outside of gtk+. Glade for example is not part of Gtk+, but it is an essential tool, we want to give that notion. Would it be great if it would be followed by the other components of the platform like GStreamer, cairo, pango, etc., and if the related sites would follow similar patterns so someone developing an application would have a familiar feeling everywhere, as part of one single platform? That's the idea, yeah, seems I'm not that crazy then ;-) -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: minutes of the gtk+ team meeting - 2009-01-20
2009/2/19 Mathias Hasselmann mathias.hasselm...@gmx.de: Am Mittwoch, den 18.02.2009, 01:54 + schrieb Alberto Ruiz: I plan to work on some other mockups of the website for other sections and I would like to get feedback from you guys. Awesome mockup! Let's get it in place! Well, first I want to come up with some screencasts of Gtkmm/pygtk. I wold also like to get MacSlows interviews from the latest Gtk+ hackfest, or record some testimonials from Gtk+ hackers and users so that people can see that this is a community project and so that they can get excited about it more easily. It won't hurt to start playing around, there are some parts of the page that I'm not sure how to arrange, like the download page. With the runtime or the runtime+headers or the sources, you can't do anything useful really. I would like to have links to the Mac OS X framework, links to Glade and in some future Gtkmm+Eclipse or PyGTK+ bundles, stuff that would make Gtk+ really useful in different platforms, an SDK rather than a library+headers. Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: minutes of the gtk+ team meeting - 2009-01-20
2009/2/19 Murray Cumming murr...@murrayc.com: On Thu, 2009-02-19 at 14:00 +, Alberto Ruiz wrote: Well, first I want to come up with some screencasts of Gtkmm/pygtk That would be great. I suggest that you get us to approve a script first though, otherwise there's sure to be some little inaccuracy that I find annoying but which would be very difficult to correct in the finished video. That's actually a good idea, I'll poke jdahlin as well. -- murr...@murrayc.com www.murrayc.com www.openismus.com -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: minutes of the gtk+ team meeting - 2009-01-20
2009/2/19 Mathias Hasselmann mathias.hasselm...@gmx.de: Am Mittwoch, den 18.02.2009, 01:54 + schrieb Alberto Ruiz: I plan to work on some other mockups of the website for other sections and I would like to get feedback from you guys. Awesome mockup! Let's get it in place! Also, my HTML/CSS-fu is quite lame. I definitively need help implementing the site, web volunteers are welcome! I can work on the graphics and the content though. Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
2009/2/11 Matthias Clasen matthias.cla...@gmail.com: With 2.20 winding down, I think now would be a good time to talk about what should happen in Glib 2.22. One thing that has been tossed around for a long time is that it would be really good to have DBus support on the Glib level. Would this support be optional? I'm concerned about making GLib dependant on a dbus development environment on Windows as DBus has no regular windows builds whatsoever (AFAIK). This would allow us to move forward with several things in GTK+ that will work much better if they can use DBus: - session support - unique application support Would DBus be swappable here for something else on non freedesktop environments? (Windows, Mac) Let me list some, with possible answers: -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Working on 119189 this weekend
2009/2/6 Matthias Clasen matthias.cla...@gmail.com: 2009/2/5 C.J. Adams-Collier c...@colliertech.org: Hey all, I'm planning some time to work on 119189 this weekend. I'm going to see if I can put together a patch to add gtkgl.c and friends into gtk. http://bugzilla.gnome.org/show_bug.cgi?id=119189 Behdad has suggested (and correct me if I've got this wrong, Behdad) that he feels that instead of creating a dedicated OpenGL drawing widget (similar to GtkDrawingArea), it would be better to add a method to the API which allows a widget to be imbued with the ability to have OpenGL primitives drawn to it. What are your thoughts? I agree with Behdad. A GL widget may be handy for the few applications that can use such a thing, it doesn't have a particularly strong reason to live in gtk itself. On the other hand, I don't want to make you too much hope for landing any new drawing api, before the clientside window work has been settled and landed. I would like to point out that while I agree with Matthias, I think is still worth working on it and you should go ahead with your enthusiasm. Libglade is an example of a quite useful library that was outside of Gtk+ all these years before GtkBuilder came along and it's been an essential part of most major Gtk+ applications. I think you should try out your ideas and keep us up to date here in the list with your progress, and of course, follow the advice of people like Behdad and Matthias. The library being out of Gtk+ shouldn't stop your willingness to contribute ;-) -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pixmap based animation in Gtk+
2009/2/4 Hagen Schink hagen.sch...@st.ovgu.de: Hello devel list, some weeks ago I wrote an email regarding Animation in Gtk+ to the mailing list. I used the passed time to implement the stated idea. Here is a video of the first results: http://video.google.com/videoplay?docid=793477820753124601 I can't believe my eyes! I'm blogging this straight away. The implementation so far is more a proof of concept and there are still enough problems to solve but I think it can already be a basis for further discussion on this topic. That is why I opened a bug report [1] and published a patch together with a small explanation and a simple test application. I wonder if you can avoid the composite requirement with Alexander Larsson's work? Alex? Anyway, so freakin' great work! Can't wait to see what we come up with during the hackfest :-) I'd really like to hear some opinions on this approach. Thanks for the help! Kind regards, Hagen [1] http://bugzilla.gnome.org/show_bug.cgi?id=570479 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
