Re: Minutes of the GTK+ Team Meeting - 2008-09-23
Hi, Why not simply keep gtk_hbox_new and gtk_vbox_new? I can see a number of reasons for doing so: 1) They are used all over the place 2) The cost of maintaining them are next to zero 3) They make sense on their own, gtk_hbox_new instead of gtk_box_new (HORIZONTAL, ...) I think removing the classes but keep gtk_hbox_new/gtk_vbox_new that simply creates a GtkBox with the correct orientation is the right approach here. Just my thoughts, Micke 24 sep 2008 kl. 17.51 skrev Michael Natterer: On Wed, 2008-09-24 at 11:23 -0400, Morten Welinder wrote: I don't think the minutes reflect what was said in the meeting here. My understanding was hat the H/V subclasses get deprecated as soon as the code to enable flipping in their parent classes is in SVN. If, say, gtk_hbox_new was to get deprecated and disappear in 3.x then it would be near-impossible to write a program to compile against both 2.x and 3.x How is this different from any other deprecated function that got replaced by another one and will disappear in 3.0? --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Hi, Just one thing, the entire starting point of our discussions around GTK + 3.0 was to avoid the 1.2 -> 2.0 pain. The proposed 3.0 is nothing like the 1.x->2.0 migration so I'm a bit unsure on the relevance of looking into these pains (other than to point out that they will not be there this time). The initial proposal was very careful with introducing new features that applications would have to port to for this very reason and we focused on what we believe are necessary cleanups and sealing in order to be able to continue to develop the toolkit at a feasible rate. A suggestion that came up in the post-guadec discussions was to move deprecated widgets to libgtk3-compat instead of removing them. This means that applications using these will have to add that as a dependency to his code base in order to continue using them. Off the top of my head this sounds like a good suggestion to me. The 1.x -> 2.0 change was painful for everyone who had an app that needed porting, however I find it pretty irrelevant in comparison to 2.x -> 3.0. Cheers, Mikael 16 jul 2008 kl. 22.51 skrev Morten Welinder: Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile... (e.g., I remember doing that for gftp, not a trivial app.) That sounds like a serious case of selective memory. Or maybe gftp has the ui from "hello, world". Here's a partial list of suffering that we went through. Let's see... * All widgets has to be reworked and audited. There was new reference handling and double destroy calls added to the trouble. * All glade files needed to be redone, or at the very least subjected to heavy post-translation surgery with Emacs and Perl. * All code needed to be audited for UTF-8. * All font handling had to be reworked. Drawing changed too. * Whenever something crashed, leaked, or otherwise simply did not work, we had to audit not only our own code, but glib, pango, and gtk+ too. There were piles and piles of bugs in the new code. * We had to struggle with sluggishness of the resulting gtk2 application. The above is just what I can remember off the bat and is *before* changing to use the new widgets of gtk2, some of which were only partial replacements of what they deprecated: the tree view, for example, was touted as right for all kinds of tables, but it has become clear that it cannot handle large ones. Gnumeric has about 34k lines dedicated to dialogs, not including code that implements the actions of those dialogs. Add to that 20k lines of widgets and another 20k lines of further gui code. That excludes code for graphs. You just do not audit that in a weekend or two. You want us to go through some variant of that every 3-4 years? That's insane! What, exactly, is it that is hard about maintaining 2.x that will not be hard for 3.x? I have seen nothing but unsubstantiated assertions about this. What I have observed is that sub-systems like GtkPrint get dumped in and abandoned right away. With bayesian mind that tells me that the maintenance situation will not be better for 3.x What really bothers me is that people go out of their way to break working code. Looking at svn logs tells me that the effort of keeping the old widgets and methods around is minimal. It's not just the old gtkclist -- the recently deprecated gtktooltips shows the same thing. The second unsubstantiated assertion is that the deprecated widgets cause a lot of maintenance work beyond the self-inflicted pain of deprecation. The data does not support that assertion. I would like to see all this gtk3 talk pushed 3-4 years out into the future. There are lots of things that need to be fixed and introducing new, buggy code elsewhere is not going to fix it. If that means the world will have to wait for animated, semi-transparent widgets, then that would be fine. No real work will get done of behalf of those features anyway. Morten Welinder PS: For whatever it's worth, GnuCash also took years to go gtk2. ___ 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: About GTK+ 3.0 and deprecated things
Hi, Because the ABI is incompatible. Apps will need to be recompiled against the new version. Also, it is not API compatible with latest GTK+ without the flags. Cheers, Micke 17 jul 2008 kl. 05.03 skrev Paul Davis: On Thu, 2008-07-17 at 04:11 +0200, Sven Herzberg wrote: Paul, just in case this wasn't made clear enough already; the GTK+ team want to deploy a GTK+3 that will be API-compatible to the latest GTK +2 including all deprecation flags that are there (disable deprecated, multihead safe, single header include, etc.). if its API compatible, why a change in major version numbers? ___ 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: About GTK+ 3.0 and deprecated things
Hi, 16 jul 2008 kl. 12.33 skrev Colin Leroy: On Wed, 16 Jul 2008 12:18:24 +0200, Mikael Hallendal wrote: Hi, It sure would lessen the burden for applications still using deprecated widgets (which is the hard part of the ABI break). Well, the hardest part in my opinion, for free software at least, is the API break :-) Sorry yes, meant the API break :) There's something unclear from the State of the union slides I've read (I wasn't at GUADEC...); What will happen to GTK+2 when GTK+3 is out ? I think that comes down to whether people are interested in investing in GTK+ 2.x (either with resources or money). Cheers, Mikael -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Colin Leroy skrev: On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote: Hi, Hi, IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. Well, they do work for us. When GTK+ 2.0 was released six years ago, we were already too busy with the rest of the rewriting code-that-worked to do it. Two years and nine days, exactly, between the first commit to the GTK2 branch and the first GTK2 release after 497 commits. And we never came to replace the GtkCtrees because a) they work and b) we didn't have the time/motivation. The tooltips should be easy to port, the tree and list widgets less so, which is why it should have started quite some time ago... and the GtkItemFactory are huge to port too. And probably there is more; I've just looked at the first batch of compilation errors using GTK_DISABLE_DEPRECATED. As Mathias said, a libgtk-legacy (or -compat or whatever) seems a good idea and (in my application developer's opinion) least that can be done for the users of the GTK+ lib. Having a libgtk-compat library sounds like a good idea. We discussed it during Guadec a year or two ago but the discussion was then about whether it would be possible to move the deprecated calls into a separate library without breaking ABI which from my understanding it isn't on Linux. It sure would lessen the burden for applications still using deprecated widgets (which is the hard part of the ABI break). Cheers, Mikael -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-doc migration
Hi Stefan, This really is awesome, thanks a lot for putting in this work and for your continues effort to develop gtk-doc. As you know I migrated the Loudmouth docs yesterday and except for that minor issue that you helped me with on IRC it worked out perfectly. Thanks, Micke 22 jun 2008 kl. 12.14 skrev Stefan Kost: hi, Stefan Kost schrieb: hi, as discussed in the team meeting on 2008 june, 3rd, we will move all api docs from tmpl files to inline source comments. This is the wiki page for coordination : http://live.gnome.org/GTK%2B/TaskAPIDocMigration I'll start with glib/gobject today. I'll be on irc the whole weekend (ensonic). Stefan I am done with glib/gobject. There is a one file left: docs/reference/gobject/tmpl/gobject-unused.sgml If someone could confirm that none of the docs in there are neded anymore, it can be wiped. For now just empty it and left the file there. Once we're done with glib/glib we could switch to tmpl-free build. Its a bit faster and it does not create those tmpl files at all. Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
Hi Gustavo, 6 jun 2008 kl. 19.22 skrev Gustavo J. A. M. Carneiro: >> You just need to remember, nobody is forcing you to use Gtk+ 3.0 or >> even >> Gtk+ at all. > > That will not be true in practice. Once Gtk+ 3.0 comes out, Gtk+ 2.0 > will die a slow death, and projects have to switch to Gtk+ 3.0 > eventually. Please note the difference between Gtk+ 3.0 and Gtk+ 3.2 and beyond. Gtk+ 2.0 is already doing a good job at dying slowly and many have already agreed that Gtk+ 2.x is a dead end. What is meant by "nobody is forcing you to use Gtk+ 3.0" is simply, since there won't be features packed into it you don't need to move to it in order to get the latest and greatest. It is a way for you as an application developer to get *more* time to ensure that your code works with the 3.x branch before the feature release 3.2 is out that you probably want to move to. > I think I agree with Muntyan here. Gtk+ 3.0 brings nothing > exciting, so > why break API? It's just so pointless and painful for everyone. So > much effort done with memory profiling and now we'll have to have two > libraries, gtk+ 2.0 and gtk+ 3.0, side by side, for a few more years? As outlined numerous times it is a conscious decision to separate features from break for the exact reasons you mention. Everyone who was around during the Gtk+ 1.x -> Gtk+ 2.x transition remembers that it was a painful exercise to migrate (and some still haven't taken the step). Gtk+ 2.0 was had a lot of new features and broke the API in many ways that made it really hard for application developers. This is not the kind of break we are talking about with Gtk+ 3.0, it's a way smaller break that most importantly doesn't change the application logic in any way. > If, as I suspect, Gtk+ 3.0 is more of a marketing stunt than anything > else, great, we can release the next gtk+ 2.x as two separate > libraries > and header files: I can assure you that Gtk+ 3.0 has nothing to do with marketing and if anything it is a bad marketing move to bring out a new major version without major features. Gtk+ 3.0 is about bringing us out of the current dead end, improve the maintainability of the library and provide for a *smooth* migration to a new development policy that will enable the Gtk+ team to incrementally improve the library. > 1. gtk+-3.0: only the non-deprecated APIs > 2. gtk+-2.0 deprecated: only the deprecated APIs > > $(pkg-config --libs gtk+-2.0) would yield -lgtk+-2.0 -lgtk+-3.0, > while $(pkg-config --libs gtk+-3.0) would give -lgtk+-3.0. > > Everyone will be happy. Projects that compile with gtk+ 2.0 with > GTK_DISABLE_DEPRECATED automatically become "gtk+ 3.0 ready". That is exactly what will happen, if your application compiles with GTK_DISABLE_DEPRECATED and GSEAL_ENABLE you are good to go with Gtk+ 3.0. Though the linking will probably not look as you suggested above but I don't see that there is a difference. The idea is to make the transition from 2.x to 3.x as painless as possible and if your code compiles with the latest 2.x with GTK_DISABLE_DEPRECATED and GSEAL_ENABLE it will also work on Gtk+ 3.x. Best Regards, Mikael Hallendal -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib and Xlib
Hi, I don't entirely understand your question. GLib and Xlib aren't really comparable. GLib is a utility library that adds hash tables, lists, IO abstraction, platform abstraction and also an object system used by GTK +. If I misunderstood, could you please elaborate a bit on what you meant? Cheers, Mikael Hallendal 6 jun 2008 kl. 00.38 skrev jaafar EL GONNOUNI: > Hello; > > What is glib adding that the GTK + compared to Xlib ? > > All what is possible with glib with Xlib is feasible, then why > create a new library. > > Best regards. > > -- > EL Gonnouni Jaâfar. > GSM : +21266682150. ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
Hi, 4 jun 2008 kl. 15.11 skrev Morten Welinder: >> (things that developers of client code >> have been wanting for years, such as the removal of deprecated code >> or >> the mangling of fields), > > As an application developer I can assure you that we as a group are > not actively looking for ways to break our applications. If the urge > should arise then we can simply sort the contents of our source files > or randomly flip bits. In other words, you need not waste precious > GTK+ resources on the problem. > > Jokes aside, try not to be cool for the sake of being cool. It was > painful > to migrate from GTK+ 1.x to GTK+ 2.x. Many applications didn't make > it for years. I take it that the original quote was ironic since removing deprecated code or mangling fields are not done to please the users of GTK+ but are necessary steps to continue developing GTK+. No one is suggesting breaking GTK+ for the benefit of application developers. This is also the reason we aim to make the transition from 2.x to 3.x as pain free as humanly possible (everyone is well aware of the pain involved in the transition from 1.x to 2x). Cheers, Micke -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
26 mar 2008 kl. 11.10 skrev Murray Cumming: Hi, > On Wed, 2008-03-26 at 10:18 +0100, Mikael Hallendal wrote: >> 25 mar 2008 kl. 08.58 skrev Murray Cumming: >> but it's not given and GTK+ is not only for GNOME. The GNOME >> bindings include (and require) a wider set of library bindings than >> GTK >> + bindings. > > You're saying it's a disadvantage that bindings for other libraries > are > available too. No, I'm saying that the fact that a binding doesn't include certain GNOME libraries or follow GNOME release schedule shouldn't move it to some secondary citizen table for GTK+ which is used widely outside of GNOME. For example the C# bindings are not on the GNOME bindings page, even though it is one of the most used and high quality bindings for GTK+. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
25 mar 2008 kl. 08.58 skrev Murray Cumming: Hi, > On Wed, 2008-01-30 at 17:26 +0100, Murray Cumming wrote: >> On Wed, 2008-01-30 at 15:41 +, Martyn Russell wrote: >>> Murray Cumming wrote: >>>> On Mon, 2008-01-28 at 13:16 +0100, Murray Cumming wrote: >>>>> And I still believe that the official GNOME bindings deserve to >>>>> be in >>>>> a >>>>> separate section. >>>> >>>> I see that the site is live already. Please don't just ignore this >>>> regression. I've mentioned it before too. >>> >>> Hi Murray, >>> >>> We are not ignoring it, it is a planned change. There are one or >>> two and >>> we have had quite a few improvement requests since going live - we >>> will >>> be getting to it soon. > > This still hasn't happened and it's still infuriating me that the page > was broken. Why can't I just fix this page as I used to keep it > maintained before? Just a -1 from me regarding splitting out the official GNOME bindings. I agree that in most cases the quality for only GTK+ is better in these but it's not given and GTK+ is not only for GNOME. The GNOME bindings include (and require) a wider set of library bindings than GTK + bindings. If you want to split the tables up, I suggest that the split is on up to date bindings rather than whether they are in the GNOME bindings package. But then again, that is pretty easy to see already. Maybe just put a little marker on the bindings that are "official" GNOME bindings? C++ [1] C# Perl [1] ... [1] Included in the official GNOME bindings. Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: reg - USB and Ethernet performance open source utility
17 mar 2008 kl. 16.13 skrev Sarahana: Hi, This is the development mailing list for the GTK+ project, please stay on topic. Best Regards, Mikael Hallendal > Dear Sir > I am Sarahana, working in an embedded product concern based on > linux, i wish to have an utility to check the performance of both > USB and Ethernet, thing is that i have to cross compile the code for > my device, if you have any such open source utility, if not can you > please suggest me to go through, i would be thankful to you. > > warm regards, > Sarahana T > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
13 mar 2008 kl. 10.13 skrev Alberto Ruiz: Hi Alberto, Thanks for sharing the results of the BoF! Looks like you had a good discussion. Cheers, Micke > Hi, > this is some sort of summary of the issues discussed in the foreign > OSes BoF at the hackfest. > > Attendees: > tml, jdahlin, rhult, kris, bratsche and myself were there. > > The discussion was focussed on Win32 and OSX, and we identified the > main challenges there. > > The problems: > * We tried to identify the reason because people are choosing > wxWidgets or Qt over Gtk+, it's not a technical issue rather than a > marketing one. People feel like wxWidgets is better because they use > native widgets, improving the engine and the dialog look and feel > would help there. > * It's really hard for application developers to figure out how to > create and deploy an application out of the linux environment. We > should provide better developer tools. > * Regarding the previous point, we should provide better installers > of the Gtk+ runtime that can be reused from their development > environment so people don't have to rebuild Gtk+ themselves and > distribute a custom version. > > The status: > * Backends: rhult keeps working hard to get the Mac OSX one into > shape, it seems that we're not far to get there. bratsche and tml > are rocking on the win32 front, it's been working for a while now, > and besides some glitches, it's in an acceptable state at this point. > > * Engines: both needs some love, the win32 one is almost into an > acceptable shape, whereas the Mac OS X one still nees some love, > although it's getting along pretty well. > > *Development tools: kris got XCode integration working, it would be > nice to automate the generation of the XCode template installer and > kind of make it a mainstream process. As for Visual Studio, bratsche > and I am going to start getting into Visual Studio to see if we can > come up with something similar. > > *Packaging: On OSX seems to be pretty much there for Gtk+ > installation, not a big deal anyway. On the Win32 front we are close > to have a componentized .msi installer. > > The plans: > We splitted the target audience for this effort into two: Gtk+ > Application developers, and Gtk+ developers. We're going to focus > first in the first ones. And hold the discussion about people > wanting to hack on gtk+ using the development environments on osx > and win32. > > First step: Let's have a clear and only answer for people willing to > create and distribute/deploy applications on those platforms. > > We got to the conclusion that we should encourage apps to > redistribute gtk+ bundled with their apps, but make sure that they > don't build it themselves, so we don't have dozens of incompatible > binaries out there. > > For win32 we want to research if we could reduce the complexity of > the runtime by trying to come up with a single .dll and bundle > the .mo catalog files so we end up with less unix hierarchy involved > in the runtime. This is not a problem at all on OSX though. > > We're going to try to push this as a consistent effort between the > win32 and osx gangs. Once we have most of the goals there, we will > be able to start to send the message that Gtk+ is getting real > native :) > > That's pretty much it, If someone from the BoF feels like I missed > something please add your comments. > > Cheers, > Alberto Ruiz ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Animation framework
11 mar 2008 kl. 00.50 skrev <[EMAIL PROTECTED]> <[EMAIL PROTECTED] >: Hi Guillaume, Not a GTK+ developer per se but just wanted to say that this is great news. I guess people are busy at the hackfest but will reply later :) Sounds like a great idea to start a wiki page on live.gnome.org to get started and write down your ideas and get others involved. Cheers, Micke > Dear GTK+ devs, > > It seems GTK+ might be in need of animation facilities some day[1], > and we have > the same kind of issue[2] in pigment[3]. I was thinking that in this > case, it > might be possible to hit two birds with one stone, since both > projects are > C/GObject. I have started to design an animation library and do some > "API > tests" to see what code using this design would look like. I am > still early in > the process and haven't written a "real" line of code yet, but I > think it's > time to speak about it. Are there other people here interested in > this issue? I > guess so seeing the number of replies to the GtkTimeline bug. > > Should we start a wiki page on live.gnome where we could centralise > ideas > regarding that? Personally, I will start programming the API as > soon as I have > a satisfying API, but I will be happier if it satisfies more than > me. Also, my > employer (Fluendo Embedded) seems to agree that I work on this full > time (or > almost), so I will be able to make this advance relatively quickly. > > I have also seen that "Animation API" is on the menu[4] of the > hackfest > currently taking place. Have there already been discussions on this > subject? > What do hackfest attendants think should be done for an animation API? > > Also, I have written a blog article explaining some of my thoughts > on the > subject: > https://guij.emont.org/blog/2008/03/10/paf-animation-framework/ > > Cheers, > > Guillaume > > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=444659 > [2] https://code.fluendo.com/pigment/trac/ticket/125 > [3] https://code.fluendo.com/pigment/trac/ > [4] http://live.gnome.org/GTK%2B/Hackfest2008/Ideas > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
28 jan 2008 kl. 10.48 skrev Martyn Russell: Hi, > Bastiaan Veelo wrote: > >> Logo: fresh look, I like it. However, it looks slightly distorted >> to me, >> if it is supposed to resemble a perfect cube. As you know, all >> parallel >> lines in a perspective projection share a common vanishing point. >> This >> seems not to be the case particularly in the upper and lower edges of >> the green front face and the corresponding edges in the back. Also, >> you >> might want to consider to make the 'invisible' edges not as heavy >> as the >> others; I suggest to have a little of the face colour mixed in them >> to >> give them a shine-through appearance. > > Thanks for your thoughts, but ultimately, it is just a logo and I > think > it looks great ;) More importantly, it's just a facelift of the current logo (which has always been skewed) and some people seems to like it. The discussion about it the last time it came up (October last year). http://mail.gnome.org/archives/gtk-devel-list/2007-October/msg00017.html Cheers, Micke -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
14 dec 2007 kl. 09.27 skrev Alexander Larsson: Hi, > On Thu, 2007-12-13 at 19:19 +0100, Mikael Hallendal wrote: > >> For example, if we plan to never use the GAsync infrastructure for >> anything other than GIO there is a point to put it under the GIO >> namespace as it shows where it belongs and what part of GLib it is >> used for. It also means we can have GFooAsync later without the two >> getting confused with each other. The same for GCancellable and >> similar namespaces. > > Eh, why would we not use these for anything other than GIO. They were > specifically designed to be generic and to be used by other APIs. Please re-read the start of the paragraph you quoted. If this is the case, all the better. > Anything that has cancellable operations (things like libsoup or > whateveR) should use GCancellable. Perfect! >> Without any namespace other than g_ it gives the idea that these >> "frameworks" are used for more than one subsystem (at least to me). > > Which is why they are good names, as this is the intention. Then we agree. >> GAsync, GCancellable, g_push, g_pop, g_loadable, g_simple are >> examples >> of namespaces that would benefit from being under the GIO name spaced >> as they are too generic by themselves. > > A few of these are unnecessary taking up namespace, and I'm working on > fixing these. And here too. :) Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
13 dec 2007 kl. 12.51 skrev Alexander Larsson: Hi, > On Wed, 2007-12-12 at 16:48 +0100, Mikael Hallendal wrote: >> 12 dec 2007 kl. 14.59 skrev Alexander Larsson: >> >> Hi, >> >>> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: >> >>> >>>> A big issue is that GIO wastes namespaces massively: >>>> g_app, GAsync, g_buffered, g_cancellable, g_content, g_data, >>>> g_desktop, g_directory, g_drive, g_file, g_filename, g_filter, >>>> g_icon, g_input, g_io, g_schedule, g_cancel, g_loadable, >>>> g_local, g_memory, g_mount, g_native, g_seekable, g_simple, >>>> g_themed, g_unix, g_vfs, g_volume, g_win32, g_push, g_pop >>>> >>>> That's clearly too much and can be reduced. While these are not >>>> strictly "namespaces" (the namespace is g_), they partly clash with >>>> g_foos and g_bars we already have, or might need in the future. We >>>> stronlgy suggest to use a common g_io/GIO prefix for all >>>> functions/types in GIO. >>>> >>>> GAsnc*-> GIOAsync* >>>> G*Stream -> GIOStream* >>>> GIcon -> GIOIcon >>>> G*Icon-> GIOIcon* >>>> GCancellable -> GIOCancellable >>>> ... >>> >>> I strongly oppose this. >>> >>> While gio is a separate library these are all symbols in the glib >>> module, and while it might be a problem at times we can handle any >>> conflict issues (since we control both libs and release them >>> toghether). >>> So, I don't think the problem with this is that bad. I mean, gobject >>> doesn't call its symbols GObjectClosure, g_object_signal, >>> GObjectValue, >>> etc, and this has not been a problem. >> >> The big issue is that GIO wastes a lot (31) of namespaces for no >> purpose. While some might not make sense to put under the GIO >> namespace (GIOIcon might be one of these, I don't know), the main >> chunk of them do. > > The 31 number is a bit high, as a bunch of the listed things are > internal only and some we could remove (as discussed in this thread, > which is a good thing). Furthermore I don't think that e.g. having a > GSimpleAsyncResult class grabs the whole g_simple namespace. > > However, it is true that there parts of the g_ namespace that are > consumed by gio. However, that is true for any addition to glib or > gobject too and yet we add names there. Also, even if we used a g_io_ > prefix we should avoid name conflicts anyway. It would be very > problematic if we had both g_icon and g_io_icon types for instance. GIcon is probably one of the examples where it makes sense to not have it under the GIO namespace. I just wanted to clarify though that it's not so much for technical reasons I suggested that we namespace a bit more carefully. For example, if we plan to never use the GAsync infrastructure for anything other than GIO there is a point to put it under the GIO namespace as it shows where it belongs and what part of GLib it is used for. It also means we can have GFooAsync later without the two getting confused with each other. The same for GCancellable and similar namespaces. Without any namespace other than g_ it gives the idea that these "frameworks" are used for more than one subsystem (at least to me). I don't think the "shorter name" argument is all that valid given that g_io_ is a very short namespace either. If that is the only reason I think we should change. Also keep in mind, I'm not suggestion that *everything* should go in under g_io_, they would have to be weighted on their own merits and GIcon which is often used as an example might be one that doesn't make sense and have use cases outside of GIO. GFile, GDrive, GVolume, GVfs are examples of namespaces that (without looking closer) strikes me as valid ones without the GIO. The namespaces themselves suggest that they have to do with the IO layer. GAsync, GCancellable, g_push, g_pop, g_loadable, g_simple are examples of namespaces that would benefit from being under the GIO name spaced as they are too generic by themselves. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
12 dec 2007 kl. 14.59 skrev Alexander Larsson: Hi, > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: > >> A big issue is that GIO wastes namespaces massively: >> g_app, GAsync, g_buffered, g_cancellable, g_content, g_data, >> g_desktop, g_directory, g_drive, g_file, g_filename, g_filter, >> g_icon, g_input, g_io, g_schedule, g_cancel, g_loadable, >> g_local, g_memory, g_mount, g_native, g_seekable, g_simple, >> g_themed, g_unix, g_vfs, g_volume, g_win32, g_push, g_pop >> >> That's clearly too much and can be reduced. While these are not >> strictly "namespaces" (the namespace is g_), they partly clash with >> g_foos and g_bars we already have, or might need in the future. We >> stronlgy suggest to use a common g_io/GIO prefix for all >> functions/types in GIO. >> >> GAsnc*-> GIOAsync* >> G*Stream -> GIOStream* >> GIcon -> GIOIcon >> G*Icon-> GIOIcon* >> GCancellable -> GIOCancellable >> ... > > I strongly oppose this. > > While gio is a separate library these are all symbols in the glib > module, and while it might be a problem at times we can handle any > conflict issues (since we control both libs and release them > toghether). > So, I don't think the problem with this is that bad. I mean, gobject > doesn't call its symbols GObjectClosure, g_object_signal, > GObjectValue, > etc, and this has not been a problem. The big issue is that GIO wastes a lot (31) of namespaces for no purpose. While some might not make sense to put under the GIO namespace (GIOIcon might be one of these, I don't know), the main chunk of them do. The examples you took from GObject are perfect examples of parts that are a fundamental and big part of the GObject library and got their own namespaces. I'm sure there are a bunch of those in GIO as well, however, we should really consider it several times when introducing new namespaces. Both for future and for people trying to use the library. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Logo (was Re: GTK+ Website Review)
6 okt 2007 kl. 19.41 skrev Christophe Dehais: Hi, For what it's worth, I like it a lot! I personally like it much better than a variant of the current skewed box. Cheers, Micke > Hi list! > > Today, I got bored of my work, so I played a bit with Inskape and came > up with another logo proposition. I can't get anything inspiring out > of the "cube" design, so here is a completely different approach. It's > not very colorful, but maybe the original blue green and red colors > could find there way as some shade or reflection. > > cheers, > Christophe > > > On 5/29/07, Christophe Dehais <[EMAIL PROTECTED]> wrote: >> Keeping the cube idea, I added some perspective to it (instead of a >> somewhat flat orthographic projection). >> >> I agree with the 'fragile' remark. Maybe having glossy but not >> transparent faces ? >> >> Attached an inkscape file (with a perspective helper on one layer) >> and a preview. >> The letters should also have correct perspective. >> >> cheers, >> Christophe. >> >> >> >> On 5/29/07, Mathias Hasselmann <[EMAIL PROTECTED]> wrote: >>> Am Dienstag, den 29.05.2007, 01:31 +0200 schrieb Felix Rabe >>> (public): >>> I wonder where the GTK logo proposal went? I think it would >>> fit quite >>> well in this design. >> Actually Andreas was doing some work there. I was sent a few >> ideas and >> they looked good, but nothing further so far. >> > > I might have another proposal based on the first one from > Christophe > ready in a short while. >>> >>> Those detached, glossy faces look cool, but they also make the >>> logo look >>> fragile. Well, and "fragile" that's definitly not a term I do or >>> want >>> associate with GTK+... >>> >>> Ciao, >>> Mathias >>> -- >>> Mathias Hasselmann <[EMAIL PROTECTED]> >>> http://taschenorakel.de/ >>> >>> ___ >>> 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 -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: md5 in glib [was: Re: GtkFileChooser + thumbnails ... history?]
4 okt 2007 kl. 01.51 skrev Fernando Herrera: > On 10/4/07, Emmanuele Bassi <[EMAIL PROTECTED]> wrote: > >> [1] well, there's a bug open[2] with a patch, providing a generic >> (MD5, >> SHA1 and SHA256) checksum API; I'd like a review of it so that it >> can go >> in GLib 2.16, now that Tim branched it. > > Yes please! Last time I checked there was 18 different md5 > implementations across gnome, although some of them came from external > modules. At least we have this in out stack: That would indeed be very welcome. I also have one a SHA algorithm in Loudmouth that would be nice to get rid of. Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.12 released
14 sep 2007 kl. 06.53 skrev Matthias Clasen: > GTK+ 2.12.0 is now available for download at: Congratulations to the GTK+ team and thanks for all the hard work you guys are putting in! Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ man pages
16 aug 2007 kl. 20.20 skrev Salvatore De Paolis: Hi, > Hi there, > i would like to know if there's a future intention to add GTK+ API > as man pages > or even if this already exists. Was looking at the gtk-doc open issues and found that you already found your way to the correct place to track this request. http://bugzilla.gnome.org/show_bug.cgi?id=467488 Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: comments in a key file
Ben Combee wrote: Hi, > On 8/14/07, Tshepang Lekhonkhobe <[EMAIL PROTECTED]> wrote: >> Looking here: >> http://developer.gnome.org/doc/API/2.0/glib/glib-Key-value-file-parser.html >> >> under the section describing differences between .ini files and key >> files I find this: >> * Key files allow only comments before the first group. >> >> I saw a typical key file and found comments could be put anywhere. Am >> I missing anything? > > This means that you can't have a key that's outside of a group. > Windows .ini files allow keys that are ungrouped and appear before the > first group of the file. It probably would be better phrased as > > "No keys are allowed before the first group name, only comments." Agreed, the string is a bit confusing, added a bug with proposed update: http://bugzilla.gnome.org/show_bug.cgi?id=466768 Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Support for a new scripting language.
Giancarlo Niccolai wrote: Hi Giancarlo, Very nice that you want to make GTK+ bindings for your scripting language. While there are several subscribers to this list with a lot of experience in binding GTK+ in various languages (I'm not one of them), you might also want to join the [EMAIL PROTECTED] [1] mailing list. Good luck! Best Regards, Mikael Hallendal [1] http://mail.gnome.org/archives/language-bindings/ > Hello to the list readers. > > Sorry for being impolite and jumping in, but it seems there is no other mean > to contact GTK developers. > > I lead a project for a new embeddable open source scripting language > called "The Falcon Programming Language": > > http://www.falconpl.org > > We have just released a stable version of our scripting language and we > would like to provide a module to integrate GTK+. > > Actually, what we would like to do is to provide an abstract windowing > system, > of which GTK+ would then be the first (and preferred) driver. However, we > would glad do have also a pure GTK+ binding, or possibly both the AWS and the > binding. > > I feel most comfortable in programming with GTK+, and I regard GTK+ as the > library that allows faster GUI programming and better GUI design-from-code > (i.e. what-you-program-is-what-you-get) i've ever come in touch with; and I > know a few. > > In the past, I realized a GTK+ based GUI interface for a language called > Xharbour (an X-Base descendant), so I am not completely new to the topic. > What we're missing now are programming hands; if you or someone you know may > be interested in participate our project, please contact me or register with > the forum at our server: > > http://www.falconpl.org/forum > > Anyhow, I hope I can count on the assitance of the people in this list in our > development effort, were we in need for some advice. > > TIA, > Giancarlo Niccolai. > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
Martyn Russell skrev: > Murray Cumming wrote: Hi, Great work Martyn! >> More importantly, I'd rather not have "Gimp Toolkit" in the page >> heading. For me that's a bit like having "GNU Network Object Model >> Environment" on a GNOME page. It's not relevant, it's distracting, and >> it's a bit tacky. It's already mentioned on the About page. > > This is true, and I would have gone for just GTK+ but it is awfully > short for a title. Perhaps something like "The GTK+ Project"? "The GTK+ Project" sounds good and much better than "GTK+, Gimp Toolkit" in my opinion. Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: using ImageViewer in GTK C program
25 apr 2007 kl. 10.40 skrev kirantoday: Hi Krankumar, This list is for discussing the development of GTK+ rather than application development. There is a separate list called gtk-app- devel-list which is meant for this kind of questions. You can subscribe to it here: http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list Thanks, Mikael Hallendal > Hi I have a requirement like this. > In my Gtk C program, i will load a image on a Gtk Form and now I > should > able to preview the image, and crop the image and save the cropped > image. > How can i achieve this functionality. > Do i need to use any Image Viewer here,if so How can I use > ImageViewer in my > GTK C program. > If any example programs are available please upload them > > Thanks and Regards > Kirankumar D. > -- > View this message in context: http://www.nabble.com/using- > ImageViewer-in-GTK-C-program-tf3643891.html#a10176482 > Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
Behdad Esfahbod skrev: > On Mon, 2007-04-23 at 16:15 -0400, Martyn Russell wrote: Hi, >> Jeff volunteered to help set up gtk.org with moinmoin [2] and >> mentioned that http://www.pango.org/ and http://www.gnome-db.org/ currently >> use >> that particular Wiki. My personal view of it, is that it seems >> somewhat simplistic and might not cater for our needs? > > Drupal is a fully armed CMS. I don't see what feature of it we may need > that we don't get from a wiki engine. Moinmoin is not exactly my > favorite wiki engine, but its been serving many projects good enough. A > problem Fedora recently faced with moinmoin though is that lots of > content (like various meeting logs...) slowed down search functionality > drastically... But for Gtk+, I don't think there going to be such > problems anytime soon. Just let people edit it... I'd use Drupal over a simple wiki any day. It has several things that might come in handy over time for gtk.org. * News/blog engine, very useful for release notes and possibly a www.gtk.org/blog in the future for updates in the projects. With RSS generation. * CMS managed aggregator (create a gtk.org planet and manage it from the same admin system). * Better ACLs if certain pages require moderation (which I believe they might). * Forums integrated, there are a lot of people feeling uncomfortable asking questions through mailing lists. * Attachment handling (this is possible through many wikis as well, not sure about Moinmoin). * Localized content (If I recall Drupal came short here though and was one of the reasons why it weren't chosen for gnome.org. However this is something that is being worked on in Drupal afaik). While some of these items might not be interesting today, they might become over time. Also, we won't loose any functionality by using Drupal over Moinmoin and can even start out by using it as a wiki + news engine for release notes. And then turn on other bits as the site grows. >> Does anyone have a view on this? >> Can anyone provide a good comparison between drupal and moinmoin? >> Does anyone have a better solution to suggest? I can't compare with Moinmoin as I haven't run it for quite a bit of time but I'm very happy with Drupal for developer.imendio.com and two other sites I'm setting up with it. Keep it up, wonderful to see this being picked up! Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Build failure current head
26 dec 2006 kl. 23.23 skrev Mike Emmel: Hi, > On 12/26/06, Mike Emmel <[EMAIL PROTECTED]> wrote: >> Hi all I'm getting this build failure with the current head. >> Directfb backend >> >> Anyone else seeing this ? Yes, it breaks on all platforms not X11. >> gtkstatusicon.c: In function 'gtk_status_icon_get_property': >> gtkstatusicon.c:672: error: 'struct _GtkStatusIconPrivate' has no >> member named 'tray_icon' Took the liberty of reopening #387215 and add you to the CC-list. http://bugzilla.gnome.org/show_bug.cgi?id=387215 Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ >> Cocoa Native Port
17 maj 2006 kl. 10.29 skrev Malik NakaMura: Hi, I tried to build it on 10.4 but it does not seem to work very well, I followed all instructions displayed in this link : http:// developer.imendio.com/wiki/Gtk_Mac_OS_X/Build_Instructions but all gtk demos are instable and very bugged. I used gtk+ 2.9... As stated, it's work in process and like any such it has bugs still. Help with patches would of course be most welcome. As people might know Anders joined Apple and will not be able to continue working on this but we (Imendio) will do our best to continue maintaining this branch. > Currently I have Tiger installed, but I could dual boot with Panther and have a go > at getting it running on that first, and then try and implement new features. Given that there is still work to be done on the HEAD branch I would say time would be better spent on working on stabilizing that and to work on features than to backport to an old version of Mac OS X. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: MacOSX gtk-doc installation problems...
amir wrote: > Hi, Hi, Are you sure that you run autogen.sh with the correct path so that you use the manually installed auto* tools? Best Regards, Mikael Hallendal > I'm having difficulties installing the gtk-doc on MacOSX 10.4.3. I have > followed the instruction listed on: > <http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Build_Instructions> > but when installing the gtk-doc with the following commands: > > cvs -d :pserver:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>:/cvs/gnome co gtk-doc > cd gtk-doc > curl http://developer.imendio.com/images/0/04/Gtk-doc-hack.diff | patch > -d $PWD > ./autogen.sh --prefix=/usr/local > > > I get: > > configure.in: installing `./install-sh' > configure.in: installing `./mkinstalldirs' > configure.in: installing `./missing' > Makefile.am: installing `./COPYING' > Makefile.am: installing `./INSTALL' > *Makefile.am:3: directory should not contain `/' * > > Any idea? > > amir. > > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Imendio AB announces the GTK+ on Mac OS X port project
Imendio AB announces the GTK+ on Mac OS X port project Tue Nov 22 12:06:00 CET 2005 The GIMP toolkit (GTK+) matures to include yet another platform. This project aims to bring native GTK+ support to the Apple Mac OS X platform. The basic implementation is sponsored by Imendio AB and the work so far has been done by Anders Carlsson (of Imendio). This project means that another critical step is taken in the effort to spread this very successful library collection to all commonly used platforms. The source code is now available in the upstream GTK+ CVS tree. “In our aim to offer attractive solutions for software application development, the crossplatform availability of GTK+ is a very important piece of the puzzle” - Michael Hallendal, CEO Imendio AB Ever since Apple launched the Mac OS X platform the possibility to interoperate with the other UNIX (BSD) based operating systems and make applications cross-platform compatible has been a vision seemingly within reach. In recent years applications used in the Linux sphere have therefore become available to Mac OS X users and to some extent the other way around as well. In the Linux community the GTK+ libraries have had a great success in attracting software developers. So why is GTK+ so popular? Like any successful innovation the GIMP toolkit was introduced with great timing. It has, since the project started, evolved and been perfected trough the use in many complex applications like GIMP and GNOME. Other factors that have made GTK+ successful include: * The licensing model (LGPL) * Its rich features * Bindings to many commonly used programming languages The maturity of GTK+ is confirmed by several large commercial players like Red Hat, Novell, Nokia and Sun, all choosing it for their Linux/UNIX based applications and platforms. “GTK+ is already a powerful tool for developers. Adding native GTK+ support to the Apple Mac OSX platform will help speed adoption of open source technologies by making it more widely accessible.” - Timothy Ney, Executive Director of the GNOME Foundation When GTK+ became available on the Microsoft Windows platform the ability to easily port GTK+ based applications arose. GTK+ went from being a platform dependent Linux based toolkit to something that could function more platform independently. Still the support for the toolkit was not natively integrated in Mac OS X. An employee at Imendio, Anders Carlsson, has during this summer, sponsored by Imendio, begun such a project to port GTK+ to Mac OS X. Imendio has invested approximately $25 000 to date and are aiming to continue to support this open project. The goal of the project will be to produce the toolkit on this platform using Cocoa (the native object-oriented application programming environment on Mac OS X). For the GTK+ user this means that popular applications will become available to this new platform. Future GTK+ applications, irrespective of which operating system they originate from, will be much more easily ported to the other supported systems. For the software industry this toolkit represents the best of two worlds. The platform-native “look and feel” of the applications written with the aid of GTK+, combined with a code base that can be reused on all platforms. This reduces the cost of developing cross-platform applications or re-writing the graphical part of an existing application. Applications already using GTK+ will more easily become available to Mac OS X users. “I’m really looking forward to finally be able to put GIMP natively on Mac OS X.” - Michael Natterer, Maintainer of GIMP. The ability to use a variety of programming languages (like C#, Java and C/C++ and also script languages like Python and Ruby) is very appealing to developers. Additionally, GTK+ being an Open Source project makes it possible to change and improve the code to adapt it to application specific needs. “The GTK+ project is excited to see Imendio work on a native GTK+ port to Mac OS X, which will enable GTK+ applications to work natively on all major platforms.” - Matthias Clasen, maintainer of GTK+ Project page: http://developer.imendio.com/wiki/Gtk_Mac_OS_X About Imendio AB Imendio is a small European company employing some of the world’s most experienced and talented GNOME and GTK+ developers. Imendio focuses on cross-platform library and API development, targeting platforms ranging from embedded devices to desktops. With extensive experience in GLib/GTK+ and XMPP/Jabber, Imendio provides first class software development services. Media enquiries: Imendio AB John Laerum Tel. +46706960408 [EMAIL PROTECTED] http://www.imendio.com Read this press release on the web: http://www.imendio.com/press/show/16 -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Usage of GTK+ headers
Kalle Vahlman wrote: > 2005/10/12, Dan Winship <[EMAIL PROTECTED]>: > >>Kalle Vahlman wrote: >> >>>Is there any reason to do otherwise? >> >>Evolution switched from using the main headers to using specific headers >>a few years ago to speed up the compile time (substantially). I think >>some other apps do this as well. > > I meant things that matter. > > (compile time is not a signifcant metric for software quality in my book) What do you mean? By including only the headers you need can substantially affect the time you spend waiting for compilation, especially in a large application such as Evolution. That time can of course be used to improve you application so, in a way it can effect the quality of a code but not necessary. So I would say that's a good reason for not doing it. Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Watching filedescriptors
Soeren Sandmann wrote: Hi, > One thing I and many other people regularly need is to be notified > whenever something happens on a file descriptor. This is needed when > you write networked applications, or when you with to communicated > with spawned child processes, and in many other circumstances. > > The way you are supposed to do that with glib right now is with > GIOChannels. Unfortunately, GIOChannels are quite painful to use, and > somewhat overengineered. While GIOChannel might be a bit hard to get the first time they get the job done. Having two APIs that does essentially the same would in my opinion be more confusing. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
