Re: Using BuildStream as a module maintainer
On Fri, 2018-02-16 at 17:15 -0500, Shaun McCance wrote: > And what about doing general development work? I can't really do much > inside BuildStream's shell. And even running yelp leaves it pretty > crippled, because it doesn't have access to /usr/share or D-Bus. To run yelp with a useful set of help files I'd suggest including more components when building and opening a shell. E.g., you could use the core.bst stack. $ bst build --track-all --track-save core.bst $ bst shell core.bst bash You could also define your own stack that only contains what you really need for your test to speed things up. D-Bus is still an open issue as it doesn't work across user namespaces with different UID mappings. I have an experimental BuildStream branch where D-Bus works in `bst shell` but we have to do some more thinking before we can merge a proper solution. If you want to try it, you can use the BuildStream branch juerg/gnome. yelp works for me with that. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problems regarding jhbuild
Hi Michael, On Mon, 2016-10-10 at 14:49 -0500, Michael Catanzaro wrote: > Anyway, the problem is a bootstrap version of vala needs to be > installed as a sysdep, but we can't make a sysdep for it until the vala > developers stop pointlessly bumping their pkg-config version early > single release. We need one vala pkg-config file that's sure to be > installed, then we can add a sysdep for it. In the meantime the only > workaround is to just install vala with your distro's package manager. The pkg-config file is for libvala, which provides access to Vala's internals and is not API-stable, hence the parallel installable versions. However, it's also not needed by regular applications and libraries that are written in Vala. For bootstrapping, the dependency should be on valac, not on libvala. I'm not very familiar with jhbuild but what's the issue with a valac sysdep such as the following, similar to how the C compiler sysdep is handled? Regards, Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Power switch to actually turn off my computer
On Thu, 2014-04-10 at 09:51 +, Charles T.Smith wrote: I've spent an hour or so looking around /usr/lib/python/site-packages/gtweak and haven't found what it does yet... it occurs to me that one shouldn't have to reverse engineer a tool in order to learn how to configure something ... Can anybody point me to the configuration files which are relevant? dconf key /org/gnome/settings-daemon/plugins/power/button-power. You can use the dconf command-line tool or dconf-editor GUI to read or write the value. Regards, Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.6 Blocker Report (T-16d)
On Tue, 2012-09-11 at 09:40 +0100, Martyn Russell wrote: On 11/09/12 08:38, Mikkel Kamstrup Erlandsen wrote: As for performance issues with libicu that has never been a problem for our use cases. There might be faster alternatives, but the speed is a non-issue for the stuff that I've been doing, and the features gained vastly outweighs the perf loss. The options here really are: - Re-work Jürg's initial fix in order to handle these new cases with libunistring. Maybe providing a custom collation method which would treat 0x10fffd always as the last char and calling libunistring's collator internally. As strcoll() doesn't appear to conform to the Unicode collation rules, I don't see how we could properly fix this in Tracker. - Default to libicu instead of libunistring. However, there have been bugs reported with use of libicu which are mentioned in the bug report above. So we could just be replacing one problem with another. I'd be in favor of this for the time being. Alexandre Rostovtsev attached a patch to the ICU bug you mentioned and it's in master for a couple months now. - We fix strcoll() which we believe is what libunistring is using. This is discussed by the libunistring community: http://lists.gnu.org/archive/html/bug-libunistring/2010-11/msg8.html I would certainly like strcoll() fixed at some point, however, I'm not familiar with the code or reasons for the current behavior, and I don't have time to look into this myself. In any case, this will likely take a lot more time to get fixed (if ever) and pushed to distributions given that strcoll() is in glibc and there may be backward compatibility concerns or the violation of the Unicode standard may even have been deliberate. Writing a new Unicode collator for libunistring seems more likely, however, I'm not following the development of libunistring at all. Regards, Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A few missing 3.5.5 releases
On Tue, 2012-08-07 at 21:35 -0400, Matthias Clasen wrote: There are a number of modules which haven't had a 3.5.5 release yet, and should probably get one: gnome-control-center gnome-settings-daemon Rico Tzschichholz asked on IRC to review and apply the CUPS 1.6 build fixes before releasing gnome-settings-daemon and gnome-control-center. https://bugzilla.gnome.org/show_bug.cgi?id=679761 https://bugzilla.gnome.org/show_bug.cgi?id=679759 Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build status
On Wed, 2010-12-08 at 07:23 -0500, Matthias Clasen wrote: Here is a quick analysis of the status of builds on build.gnome.org. The one-line summary is that getting webkit and e-d-s to build against current GTK+ will get us quite a bit closer to a fully building tree. But there is also a bunch of easy fixes for make check failures. [...] Other problems: vala One test in make check fails and I assume this is due to old D-Bus version. The file descriptor passing test requires D-Bus 1.3/1.4. Any chance that could be updated? Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Vala and pkg-config
Vincent brought to my attention that there are some packages out there that use pkg-config to check for the presence and version of the Vala compiler. However, this is wrong and should be removed in all affected packages as soon as possible. The pkg-config file is installed for libvala, which is an unstable library that is only needed by development tools to, e.g., provide code completion in IDEs. All other Vala applications and libraries should not use or link to libvala and should therefore also not use the pkg-config file. I've changed the pkg-config name in the 0.9.5 release to vala-0.10 to support parallel installation with future release series. As the pkg-config file is only meant to be used with the unstable libvala library and I wasn't aware of it being used for the compiler itself, this caused more fallout than expected. Sorry about that. If you use automake 1.11+, you can use AM_PROG_VALAC([0.9.5]) in your configure.ac to check for a minimum Vala compiler version. Vala 0.9.5 also comes with a VALA_CHECK_PACKAGES macro, which you can use in configure.ac to check for bindings. To make the lives of developers, testers, and packagers not harder than necessary, please check as soon as possible that your Vala-using package does not use pkg-config for Vala compiler checks. Thanks, Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New external dependencies for Rygel: GUPnP Libgee
On Tue, 2010-06-08 at 02:24 +0300, Zeeshan Ali (Khattak) wrote: On Tue, Jun 8, 2010 at 1:52 AM, Frederic Peters fpet...@gnome.org wrote: General questions first: - Are there frequent releases of those? The GUPnP libraries, yes! libgee used to be very frequently released until recently when the new maintainer just disappeared after he moved to a new house. That said, I haven't seen any issues with Libgee after 0.5.0 release and if I (or anyone) do, I'm sure Jürg will take over and make the releases happen in time. Right Jürg? Sure, bug fix releases can happen quickly if necessary. About libgee, shouldn't this be in glib, or in the language itself, instead of an extra library? Don't know. I guess that would be a question for Jürg. It was proposed multiple times¹² to be included in glib, however, it was not accepted by the glib maintainers. The main reason was that glib already contains various collection types and these types can obviously not be removed from glib 2. This means that there would be two sets of collection types, the previous ones in libglib and the new GType and interface-based ones in libgobject/libgio, which wouldn't improve consistency within glib, although it might still have improved consistency outside glib. Vala does not have a language-specific runtime library, glib is all you need to run Vala applications. That's why a separate library has been created for the collection types. Regards, Jürg ¹ http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00144.html ² https://bugzilla.gnome.org/show_bug.cgi?id=560061 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump intltool version to 0.41.0
On Wed, 2010-02-24 at 14:02 +0100, Paolo Borelli wrote: I accepted a patch of gnome goal that updated the build system and didn't notice that version bump I do not see any strong reason to force 0.41.0, gtksourceview built just fine with previus intltool versions up to a couple of days ago. intltool 0.40.6 has a bug that breaks translations when building with LINGUAS. I'd appreciate it if we could avoid using that version in release tarballs. 0.41.0 works fine, as far as I know. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependency proposal: Vala
On Mon, 2009-10-12 at 11:10 -0400, Ryan Lortie wrote: I'd like to propose Vala as an official external dependency for GNOME 2.30. [...] This is therefore a 'special' external dependency: it would only be required when building from git (or hacking on the code). It makes sense that we depend on the most recently available version at this point -- 0.7.7. Vala 0.8.0 will be released this week and from this point on, the language syntax is considered stable and no backward incompatible changes will be applied during the 0.8 series. We also intend to keep backward compatibility with 0.8 when releasing 1.x, assuming we don't find severe issues in the syntax in the meantime. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependency proposal: Vala
On Mon, 2009-10-12 at 18:43 +0300, Zeeshan Ali (Khattak) wrote: On Mon, Oct 12, 2009 at 6:35 PM, Jürg Billeter j...@bitron.ch wrote: On Mon, 2009-10-12 at 11:10 -0400, Ryan Lortie wrote: I'd like to propose Vala as an official external dependency for GNOME 2.30. [...] This is therefore a 'special' external dependency: it would only be required when building from git (or hacking on the code). It makes sense that we depend on the most recently available version at this point -- 0.7.7. Vala 0.8.0 will be released this week and from this point on, the language syntax is considered stable and no backward incompatible changes will be applied during the 0.8 series. We also intend to keep backward compatibility with 0.8 when releasing 1.x, assuming we don't find severe issues in the syntax in the meantime. That is really good to know and takes away my main reason to distribute generated files in rygel release tarballs but what about the bindings (ones bundled with vala)? They are still far from perfect AFAIK. While I can't guarantee binding stability at this point, many binding fixes don't break backward compatibility. As Vala bindings are very close to the API of the C library there are not many structural changes in bindings, at least in bindings of GObject-based libraries. Most binding bugs are either missing memory management annotations where a fix just fixes a leak without breaking backward compatibility or it's a more severe bug where the method was previously unusable, which is also not really a backward compatibility issue. If you notice a backward incompatible change that could be avoided, please let me know and I'll try to retain backward compatibility as far as possible. However, I don't think it's really a problem to distribute generated files in general as long as you also ship the .vala sources. This has been done with files generated from, for example, bison and flex, for a long time. You should avoid putting generated files in git but you're not doing this anyway, as far as I know. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependency proposal: Vala
On Mon, 2009-10-12 at 17:52 +0100, Bastien Nocera wrote: On Mon, 2009-10-12 at 12:11 -0400, Jamie McCracken wrote: I would rephrase this as valac as a build dependency for gnome as valac is like yacc/bison/flex in that there is no runtime dependency and only people developing or compiling from git will need it (tarballs and distributed source will contain the generated c files so wont be needed there) If people can't hack from tarballs, then it's useless. I already complained to Zeeshan about that, though I'm not sure whether it's because of the code in Rygel's makefiles, or automake's vala support. Distributors will want to be able to apply patches to tarballs, and have the changes automatically rebuilt (even if that means having the vala pre-processor installed in the buildroots). If you enable maintainer-mode, this should not be an issue. It should behave exactly the same as with .c files generated by bison and flex. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 2009-08-18 at 13:57 +0100, Luis Medinas wrote: Is there plans to replace HAL by GIO or devicekit ? Hal will be deprecated soon afaik. Richard Hughes has already ported the battery handling of Tracker to DeviceKit-power. It's used if available, otherwise HAL is used. The volume handling of Tracker has not been ported to DeviceKit-disks yet, though, so we still depend on HAL for that. Also is there any plans to integrate with more applications besides nautilus ? i mean if it's for GNOME 3.0 it should be integrated with zeitgeist, gnome-shell and gnome-do if it will be proposed ? Work for integration with Zeitgeist is ongoing, some more information about this is available in various blog posts by Seif[1]. Jürg [1] http://seilo.geekyogre.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 2.26
On Fri, 2009-01-23 at 12:01 +0100, Pacho Ramos wrote: Sorry if it has been already discussed but, where can I find the original New module decisions for 2.26 message. I can only find replies to it but I cannot find the main thread: http://www.mail-archive.com/desktop-devel-list@gnome.org/index.html I only see it in the devel-announce-list archive: http://mail.gnome.org/archives/devel-announce-list/2009-January/msg6.html Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
On Tue, 2008-07-01 at 10:08 +0200, Josselin Mouette wrote: Le mardi 01 juillet 2008 à 10:30 +1200, Callum McKenzie a écrit : As an aside: ultimately it will be necessary to move it from a hacking dependency to a build dependency. Novice developers work from tarballs, not SVN and you will get patches against your generated code appearing in bugzilla. And don’t forget downstream. If patching the code requires grabbing the Vala file from the SVN, regenerate the C code and then diff it, it is going to be a big pain for us, while a new build-dependency on valac is trivial to deal with. The tarball should also contain the .vala source files and the build system should rebuild the C code when the .vala files have changed, similar to how other generated files are handled. Does this sound ok? Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
On Tue, 2008-07-01 at 11:32 +0200, Josselin Mouette wrote: Le mardi 01 juillet 2008 à 10:49 +0200, Jürg Billeter a écrit : and the build system should rebuild the C code when the .vala files have changed, similar to how other generated files are handled. This does not. Magic rules to rebuild stuff that is not supposed to change when you use a tarball often fail miserably when you use a patch system over the sources. This is why we set AM_MAINTAINER_MODE wherever possible. It should certainly be possible to guard the valac calls with if MAINTAINER_MODE I'm not a huge fan of maintainer mode but it probably makes sense to use it for valac rules to get the same behavior as with other generated files. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
On Sun, 2008-06-29 at 23:35 +0100, Bastien Nocera wrote: On Sun, 2008-06-29 at 22:02 +, Stef wrote: I've been implementing some parts of seahorse (and maybe soon gnome-keyring) in Vala. snip Barring any objections, the next release of seahorse will contain some vala code. I object. Given that I see people filing bugs against Totem whenever the Vala API changes (which is, since Totem got Vala plugin support, about 3 times) we have to make changes. Out of the three changes in Totem I've seen, we have * one incompatible change in the Vala type system, i.e. the requirement to specify Object (GObject) as base class, however, the change in Vala was 10 months ago and a trivial change in Totem * add `abstract' modifier to an abstract class, which was no change in Vala, just improved checks, we didn't enforce it before * add `throws Error' to the method declaration, which was also no change in Vala, just a bug in the bindings That said, I fully understand when people don't want to depend on Vala as long as we don't guarantee language stability, however, that will be the case for 2.24, if everything goes as planned. Also, it makes sense to allow the module maintainers to decide this, in my opinion, as long as they distribute the generated C sources. Jürg -- Jürg Billeter [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
On Thu, 2008-06-26 at 17:28 +0200, Patryk Zawadzki wrote: 2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]: Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones: Agreed, we need to move towards expecting Composited as default and Direct as a niche case, but this was just an example. :) Guess Metacity's compositor needs to become much faster first. Activating its compositor introduces such a lag, that is isn't fun anymore. That involves either: * replacing the current compositor with a GL-based one; or Please don't. I really want compositing but I can't use a GL-based one on all systems, as for example even with some recent Intel desktop mainboards you can't have DRI with a screen area larger than 2048x2048, which is easily reached with two monitors. Metacity's compositor works pretty well here except for slow workspace switching. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
Hi, On Thu, 2008-06-26 at 17:55 +0200, Dave Neary wrote: Jürg Billeter wrote: I really want compositing but I can't use a GL-based one on all systems, as for example even with some recent Intel desktop mainboards you can't have DRI with a screen area larger than 2048x2048, which is easily reached with two monitors. I don't mean to be impertinent, but isn't any screen bigger than 2048x2048 a major edge case? It's like desktop apps that only work on screens bigger than 640x480... who cares at this stage? By the time that's anything bug an edge case, won't the hardware have caught up? It's an edge case for single-monitor systems, however, I wouldn't call multi-monitor systems an edge case and you already have more pixels with two 17 1280x1024 screens (or laptop + external monitor, which is not uncommon). Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Should GNOME apps support a --geometry option?
On Wed, 2008-06-18 at 18:02 +0200, Luca Ferretti wrote: Il giorno mer, 18/06/2008 alle 11.23 -0400, Matthew Barnes ha scritto: I think I'm correct in saying the GConf approach is preferred, I don't think so. GConf keys should be used to store _user_ editable preferences[1], and I can't see how users (and sysadmins for default and mandatory values) can have any interest to set window geometry. I have strong interest in moving and resizing my windows, I don't see how this is not user editable... Can you explain why you think that GConf is not appropriate? Jürg -- Jürg Billeter [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Should GNOME apps support a --geometry option?
On Wed, 2008-06-18 at 18:15 +0200, Patryk Zawadzki wrote: On Wed, Jun 18, 2008 at 6:13 PM, Jürg Billeter [EMAIL PROTECTED] wrote: On Wed, 2008-06-18 at 18:02 +0200, Luca Ferretti wrote: Il giorno mer, 18/06/2008 alle 11.23 -0400, Matthew Barnes ha scritto: I think I'm correct in saying the GConf approach is preferred, I don't think so. GConf keys should be used to store _user_ editable preferences[1], and I can't see how users (and sysadmins for default and mandatory values) can have any interest to set window geometry. I have strong interest in moving and resizing my windows, I don't see how this is not user editable... Can you explain why you think that GConf is not appropriate? For one gconf won't let you store this per running instance (for example have 3 instances of the same app running side by side). I agree, however, that's the case where you don't have one application window but e.g. multiple document windows. Jürg -- Jürg Billeter [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Suggested even/odd convention for the micro version numbers (like cairo)
On Tue, 2007-12-11 at 13:08 -0600, Shaun McCance wrote: The problem I see with the proposed scheme is that we can't fit step (e) into it, since 2.12.2 is never in SVN. With our current scheme, you can do this: svn checkout $(url)/tags/MY_PROGRAM_2_12_2 make distcheck and get, in theory, exactly the tarball that's sitting on ftp.gnome.org. If 2.12.2 is never in SVN, that's not going to be possible. The cairo repository shows that also the even release version is committed and this commit is then tagged. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Input devices capplets
On Wed, 2007-10-31 at 18:59 +0100, Denis Washington wrote: I created two mockups for possible keyboard and mouse capplets in GNOME 2.20. Their aim is to incorporate accessibility features in both; the existing keyboard a11y features into Keyboard and the already discussed Mousetweaks settings into Mouse. The mockups can be found here: Keyboard: http://ultimum-projekt.de/mockups/keyboard.html Mouse:http://ultimum-projekt.de/mockups/mouse.html What do you think? Shouldn't we also incorporate the Keyboard Shortcuts capplet into the Keyboard capplet at the same time? Otherwise good work, as far as I can tell from a quick look. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: vinagre (vnc/rdp client)
On Mon, 2007-04-23 at 10:22 -0700, Jeff Waugh wrote: quote who=Calum Benson That was just a Java web applet checked in as a jar file, wasn't it? Yep. It just means JDS can show an http address in the vino-preferences dialog that's usable by anyone (firewalls permitting), whereas the community version shows a vncviewer command that may or may not actually be directly useful to whoever you're giving the instructions to. Perhaps if the source were checked in (or we could have a clear dependency on an Open Source project that provides the jar file), we could rectify this problem. As far as I know there is still no reliable open source implementation of a Java applet plug-in and the Sun Java plug-in is not really cross-platform, at least I haven't seen it as part of the x86_64 JRE of Java 6. IMO we shouldn't readd the applet to vino, if this information is still accurate. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Slab's CC
On Fre, 2006-10-13 at 16:43 +0200, Alexander Larsson wrote: On Fri, 2006-10-13 at 09:47 +0200, Rodrigo Moya wrote: On Thu, 2006-10-12 at 19:28 +0200, Alexander Larsson wrote: On Wed, 2006-10-11 at 16:48 +0200, Rodrigo Moya wrote: Following on this, I'm looking (and almost starting) to merge all the libs we have in c-c into a single libgnomecontrolcenter library. That means putting libbackground and libwindow-settings, and, if we all agree, libslab and libtile (while we look for a better place). Anyone has anything against this? I guess we don't have ABI/API problems, since they're not platform libraries, right? Does this mean that nautilus will have to link to this lib (it currently has a libbackground module checkout)? hmm, I guess so, although I am starting to think about leaving libbackground as it is, since it seems to not have much use outside of the c-c and Nautilus. Would nautilus depending on libgnomecontrolcenter be acceptable? It strikes me as weird an unnecessary. It might also create build loops if say g-c-c ever wants to add a nautilus extension. g-c-c already depends on nautilus for fontilus and themus, so it would definitively create a build loop... Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Mit, 2006-07-26 at 18:32 +0200, Murray Cumming wrote: On Wed, 2006-07-26 at 11:25 -0500, Mike Kestner wrote: On Wed, 2006-07-26 at 18:21 +0200, Murray Cumming wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. That seems a lot nicer. I am, however, slightly concerned that this would force people to depend on libglade even when we have a libglade replacement in GTK+. The C, C ++, Python, Java, and Perl users will be able to rewrite their applications so that they don't need libglade on the system. glade-sharp is an optional build. We're not forcing anyone to put it on their systems. These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. gtk-sharp has a separate glib-sharp-2.0.pc pkg-config file, so it's relatively easy to provide multiple binary packages from one source package or am I missing something? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Don, 2006-07-20 at 23:24 +0100, Jamie McCracken wrote: I totally agree but wouldn't it be better to use native languages that offer all this like the D language (http://www.digitalmars.com/d/). No one has ever justified why we need a VM given all its disadvantages (speed - especially when mixing with native code, startup time, resource usage, bloat etc) Also managed languages can still leak and crash and misbehave if the p/invoke is not done properly so it aint a silver bullet. The D language offers the best of all worlds IMO *without* compromising on speed, resource usage or bloat. It would be madness to use a VM instead! (of course its not as integrated into Gnome yet and lacks an IDE but if someone puts the work in you will have a killer platform than no VM based platform can match) You might be interested in looking at Vala http://www.paldo.org/vala/ . It offers similar advantages as D does but with one major addition: it has been designed for GNOME (resp. GObject). I assume you can't subclass D classes from C (via GObject) or other languages, so it's only usable for applications but not for GNOME libraries. Vala uses the GObject type system as its native type system and bindings for GTK+ and other GNOME libraries are only needed at compile-time, not at run-time. It's not ready for production use yet but it's available for testing now and with feedback [hint ;) ] from interested developers I believe that we can get a very nice development environment for GNOME ready in relatively short time. Regards, Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
On Mon, 2006-07-17 at 07:55 +0200, David Nielsen wrote: søn, 16 07 2006 kl. 23:33 -0500, skrev Jason D. Clinton: While you provided a fine run down of arguments, I believe you forgot a vital one, Mono can be optimized, we can cut down ressource consumption, we can indeed do better - we cannot however make C development as fast development in C#, nor as fun. Twice the memory consumption is as I Well, you can't make C development as fast but that doesn't mean that all unmanaged languages are unsuitable for RAD. I'm trying to create a language[1] with many features from modern programming languages without any runtime overhead and it doesn't seem to be impossible. Jürg [1] http://www.paldo.org/vala/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.15.x: 'loading theme icon for stock' problem persists...
On Mit, 2006-06-07 at 14:05 -0400, Joseph E. Sacco, Ph.D. wrote: I just tried out Frederic's suggestion: * uninstall gtk+-2.9.2 * extract the source from the f.g.o tarball * rm gtk/gtkbuiltincache.h * build * install The bad news is I still see the error. Should be fixed in CVS http://cvs.gnome.org/viewcvs/gtk%2B/gtk/Makefile.am?r1=1.309r2=1.310 The patch applies to Makefile.in in the 2.9.2 tarball, too. Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: API documentation requirements for next releases
On Fre, 2005-12-02 at 10:33 -0500, JP Rosevear wrote: Is there a deadline for when this has to be done by? Getting to the hard freeze and then realizing, oops not done, but people now depend on the API would be a bad thing. Deadlines In each release cycle, the deadline for API documentation of new API is one week after API freeze. Lack of compliance will be treated the same as freeze breaks. http://live.gnome.org/ReleasePlanning/NewApiDocs Jürg -- Jürg Billeter [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
