Notice of award! (was GNOME User survey)
The Committee for Internet Discussions and Heated Arguments (TCFIDAH) would like to announce that we have decided to give out one of our most coveted awards. So let it be known we would like to give Felipe Contreras the 'oGalaxyo Honorary Memorial award for Endurance in Online Arguing' for his outstanding contributions to the GNOME community over the years. The committee states in the announcement press release: 'It is rare occurrence when someone steps forward with such a fervor and passion, committed to a crusade proving the incompetence and laziness of everyone else in the world. If we don't give out an award for this what could we possibly give out an award for!' Based on past experience the committee can also say that we are expecting Mr. Contreras to be a future good candidate for the Goneme desktop excellence award. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
On Fri, 2010-07-09 at 16:53 +0200, Maciej Piechotka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > On 09/07/10 16:37, Christian Fredrik Kalager Schaller wrote: > > I would strongly prefer glib to not change its license, we are keeping > > the lgplv2.1 in GStreamer, partly because a lot of people making > > products with GStreamer prefer it over lgplv3. If glib switched under us > > it would make our license stability a bit of a joke. If someone wants to > > use glib under the lgpl3 they can do so now with the current license, if > > upstream changes however, people can not keep using it under the > > lgplv2.1 without forking. > > > > Christian > > > Not quite true. You can link LGPL 2.1 project with LGPL 3.0 library > according to FSF. > > IANAL but LGPL is not viral license and you can link anything with it. > > Regards That is true, however it still adds LGPLv3 to the licensing stack people have to relate to and deal with. So while the license isn't viral it still means people have to use a LGPLv3 licensed library in order to use GStreamer. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
I would strongly prefer glib to not change its license, we are keeping the lgplv2.1 in GStreamer, partly because a lot of people making products with GStreamer prefer it over lgplv3. If glib switched under us it would make our license stability a bit of a joke. If someone wants to use glib under the lgpl3 they can do so now with the current license, if upstream changes however, people can not keep using it under the lgplv2.1 without forking. Christian On Thu, 2010-07-08 at 14:01 -0400, Matthias Clasen wrote: > On Mon, Jul 5, 2010 at 10:48 AM, Ryan Lortie wrote: > > hi Everyone, > > > We have 3.0 upon us now, so I guess we should make a choice one way or > > another. > > I think any attempts to relicense the bigger platform libraries like > gtk or glib would end like the dbus relicensing efforts. > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
Hi, > FWIW, I've been advocating for a while that, for example, GStreamer > should aim to provide everything an application needs - ie. a complete > framework. This came up when Cheese was being ported from HAL to use > libgudev for device discovery. Now, the actual device interaction > already happened in GStreamer, e.g. you use the v4l source and pass it a > device file. But device detection etc. was missing. Having all that in > GStreamer will make Cheese easily portable to Solaris, Windows, OS X and > so on (and AFAICT these changes are happening in GStreamer so kudos to > these guys). Funny you should mention this cause the GStreamer team had some discussions with Alexander Larsson among others about having glib support for device detection. I guess the conclusion is that also the GStreamer devs agree a cross platform device detection setup would be nice, but I guess there is still some disagreement on where it belongs :) Anyway, I like your suggestion for the 3 tiered stack as it should give everyone involved a clear idea about what the GNOME community will undertake to ensure works across all platforms and what the OS communities themselves need to take care of. My hope is that someone like the release team would issue a statement with what our guidelines are currently, in relation to these issues, as I feel we are in a very freewheeling stage now where the boundaries for when platform specific stuff is a feature and when its a bug is constantly changing. Adopting something along the lines of your proposal would help clarify the situation and people working on Solaris and FreeBSD for instance would at least have something clear to work from. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME and non-linux platforms (release team please stand up)
A topic that was discussed in the hallways in Gran Canaria is the fact that GNOME has gone from not letting non-linux platforms hold back development of features (ie. introduction of HAL) to making choices that basically means we are abandoning any attempts of allowing GNOME to run on non-linux platforms. The switch from HAL to udev is maybe the clearest one, but the push towards PulseAudio for a lot of things have the same effect, as I think Lennart has said multiple times that none of the non-linux systems like Solaris or FreeBSD got a sound system capable of supporting PulseAudio. Personally I don't necessarily object to this choice, as giving 95% of our userbase a better and more competitive experience critical for future growth, and trying to come up with lowest common denominator abstractions might be a hindrance for that, but I do object to the fact that we are making this choice without actually having made it. So I would like to ask the GNOME release team to please come forward and clearly state that the future of GNOME is to be a linux desktop system as opposed to a desktop system for any Unix-like system. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
mDNS vs Upnp was Re: Platform
I can't help but feel that this discussion about Avahi versus gupnp is rather construed. Most application developers will go looking for either of these technologies because they want to interoperate with a specific set of non-GNOME devices. If you want your video player to be able to send video directly to a DLNA certified TV for instance you probably couldn't care less whether Avahi is the officially blessed stack for these sort of things, cause Avahi doesn't do what you need it to do. And the other way around if you are trying to integrate with Apple hardware you wouldn't give a damn if gupnp was the official stack for these sort of things as it wouldn't do what you need it to. The only usecase where a developer might care which one is 'officially blessed' would be in the GNOME to GNOME usecase, but I honestly believe that is a tiny minority of the usecases. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mac shipments up 12% [Was: focus!]
On Thu, 2006-07-20 at 22:57 +1000, Jeff Waugh wrote: > > > > > It's the growth and potential that worries me. :-) > > > > They've had better software and better hardware than Windows for a full > > five years, and have still not cracked 5% market share, so I don't see why > > you're scared now- they've had good quarters before, and they end up > > getting lost in the noise. > > They haven't had better software/hardware *momentum* for five years. > > Their platform is now at a point that Mac developers can be *extremely* > effective with vastly less work than Windows or Linux developers - which > means more software, more developers, more polish, a bigger ecosystem... > Sorry Jeff, I simply don't see it. Neither the momentum you are seeing or the sudden incredibility of their platform. If anything it seems the major Mac software developers like Adobe and Microsoft is still trimming down their MacOS X support, slowly but surely. Just my perception of things of course, but looking out the window on my side of the pond I simply don't see the big Apple waves anywhere. So the general market was up 11% and Apple beat that by 1%. On the the other side it would be natural to think that at least a couple of Apple's percentages came from customers who boosted the periods sales due to having been waiting on the Intel based Mac's before doing their planed purchase. If that is the case then Apple's 'normalized' sales for the period would be up 9%-10% which means they lost market share to the PC market relatively speaking. Anyway, Apple's fortune's are a bit off-topic for this list. My original point was simply that we should be very careful about fan boying Apple and believing that mimicking Apple is our way to success. We are part of a community of people who tend to value computer related things quite a bit differently from the market at large. I am sure that among GNOME and GNU/Linux users we will find many people who thought things like OS/2, Amiga OS and BeOS was the next big thing back in the day based on the technical qualities of said systems. When I hear people singing MacOS X praises today it seems to me its using the same tune as the praises sung to those operating systems of yesteryear. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Actually I have to say we should stop idealizing Apple that much, they are a company which basically has gone from being the desktop leader to today being a fringe player. They have survived partly by clinging onto a couple of niches like graphical design and to some degree education. They have over the last few years managed to grow a little into the tech geek segment and the multimedia market, but even using things like iPod and iTunes to push their desktops they seem to have managed little apart from not slipping further down in market share and instead staying around their allotted 4% to 5%. I am not saying we shouldn't take good ideas etc., from Apple, but lets try to remember that Apple is basically a failure in the desktop market. Nothing objectively wrong with many of the approaches Apple takes, but obviously the market doesn't care enough about them to reward Apple with any significant market share gains. Over the last decade there has been many 'must have' technologies hyped which turned out to marginal and worthless. For instance many of probably remember that one of the last battles fought in the browser wars where in the area of 'push technology'. All analysts seemed to agree that who of Microsoft and Netscape that managed to come up with the best push solution would be the winner of that generation of browsers. Well both active Desktop and Netscape Netcaster was released with much fanfare only to relatively quickly fade into obscurity and be discontinued. Apple's 'cool' is a bit like 'push technology' it is this thing people talk about, but if you look at the marketplace it isn't obvious it matters. Christian On Tue, 2006-07-18 at 18:57 +1000, Jeff Waugh wrote: > > > > All this talk about the "target audience" scares the hell out of me. > > Because if is decided that the target audience is the white collar office > > worker (or some other stereotype I don't belong to) it means that GNOME > > wont benefit me anymore. > > That doesn't have to be true. Consider OS X - if anything, their target has > been 'creative professionals' (which reaches into all kinds of places) for a > long time. But they've been able to amass a *huge* number of hacker and geek > users with their development platform, UNIX heritage, 'just works' approach, > and lustful upmarket / cool kids attractiveness. > > "Picking an audience" doesn't necessarily mean picking *only one* audience. > > :-) > > - Jeff > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gst-devel] GStreamer in GNOME 2.16
Hi, As Mike mentioned in another mail I don't think there are anything major affecting current applications apart from continuing improvements in plugins and addition of more plugins to support more formats, protocols and so on. I think the most major planned changed is the USB device handling stuff that Jurg has been working on: http://bugzilla.gnome.org/show_bug.cgi?id=329112 The GStreamer parts of this are already merged for some time, but we are still waiting on the control-center part to get merged. There are some bigger projects planned, such as a rewrite of our decodebin plug-in used by almost all GStreamer using playback applications, but there should be no impact of this on applications or GNOME apart from more things working/being possible. I think for playback we are in a polish mode currently with almost all the plugins we really need already there. A lot of the development focus now is on enabling new non-playback applications like Pitivi, Diva, Thoggen, Jokosher and Buzztard, Tapioca and Telepathy. I doubt any of these applications will be ready for being proposed for 2.16, but at least some of them would be ready in the 2.16 timeframe. Christian On Tue, 2006-04-25 at 22:41 +1000, Jeff Waugh wrote: > Hi all, > > Just wanted to check what the plans are with GStreamer over the next few > months leading up to the GNOME 2.16 freeze period, such that both projects > can plan around (within?) our release schedules. For instance, are there any > major changes that will impact GNOME 2.16 development, are there GStreamer > related features that ought to be adopted in this timeframe, etc. > > If so, it would be useful if we could mail devel-announce-list with an > outline of our plans, and recommendations for developers working with > GStreamer in the GNOME 2.16 timeframe. > > Thanks, > > - Jeff > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager
On Mon, 2006-04-10 at 11:59 +0200, Xavier Bestel wrote: > On Mon, 2006-04-10 at 01:28, Corey Burger wrote: > > On 4/9/06, Andrew Sobala <[EMAIL PROTECTED]> wrote: > > > Elijah Newren wrote: > > > > On 4/9/06, Scott J. Harmon <[EMAIL PROTECTED]> wrote: > > > > > > > >> Am I the only one who mouses over the applet to see how much more time > > > >> until the battery is fully charged? > > > >> > > > > > > > > Definitely not; I rely on this frequently. I'd be heavily annoyed if > > > > the applet wasn't showing (and no other equally easy way of obtaining > > > > this information was available) when my laptop is plugged in and not > > > > fully charged. If it's both plugged in and fully charged then I'd be > > > > fine with it not being there, as long as that was the only case. > > > > > > > Hmm. In this configuration, it is. > > > > The problem with hiding in this case is that the user must know that > > when they are plugged in and fully charged, the icon will vanish, > > rather than just looking and seeing that they are fully charged and > > plugged in. Ouch. > > Well, if once the battery reaches 100%, a short-lived notification > bubble says so then the icon can disappear without harm. No need to > pollute the notification area with a "battery is full" icon, OTOH on the > road the fuel gauge is important. > > IMHO the best design is found in PocketPC2003: the battery icon starts > to appear only when it's half-empty. > While this debate about people's battery status preferences is extremely interesting and intellectually challenging I think its on a level of nitpickery that belongs on either some HIG related list or in bugzilla. The actual question at hand is, Is GPM ready to go into GNOME 2.16? That is a yes or no question, it is not a request for people to pipe up with marginal feature request of the day or state their vision for notification/applets in GNOME. If people want to design and code a new way for doing notification applets please do so and it will probably have a good chance to go in, but if you are only interested in sharing your feelings with the world on battery notification or applets in general please do so somewhere else. This is the desktop-devel list, not the desktop-feelings list. Personally my answer to the is GPM ready question is yes. A big thanks Richard for his work on GPM. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
Hi, I think our thinking historically has been that distro's who really care about GNOME don't really 'care' that much about our list of stuff in the desktop release as they have a pretty good idea themselves what they want/don't want. Distro's which don't care much about GNOME on the other hand might look at our desktop release list, as a guide at least, for what to package. So for instance KDE focused distro's who wants to be able to checklist GNOME might look at it to see what should be packaged. Christian On Fri, 2006-02-17 at 09:11 -0500, Dan Winship wrote: > Murray Cumming wrote: > > On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: > >> - David's recent point in this thread about the desktop release set > >> not being so important also rings true to me. It's a binary in-or-out > >> yet there are lots of really rocking "Gnome" programs that are well > >> integrated but aren't in the set. > > > > It's foolish to imagine that being in the desktop release set is > > essential. But it's also foolish to ignore the big benefits to focusing > > our efforts (in a synchronized way) on particular implementations of the > > features that we want. It allows us to release software for distros to > > use. > > Do we have any evidence that any distro actually cares what we consider > to be in and out of the desktop release? Is there some distro out there > loyally shipping epiphany as its default browser and waiting for us to > certify GIMP before they allow it into the default desktop install? > > -- Dan > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: requesting official list of modules and versions for GNOME 2.14
Ask and thou shall receive :) > - asf and multi-language .mkv/.ogm files still don't play, .mpg > functionality is still heavily limited although basic playback works Edward (bilboed) ported the ffmpeg demuxers. All ffmpeg demuxers including asf (and the weird game formats) now work. Including seeking. > - subtitles embedded in movies (.mkv, .ogm, dvds) still don't work Still not ready, but Martin Soto and Edgard Lima is working on it now. > - language selection (audio tracks, subtitles) still doesn't work Jan has a stream selection design done. But this still need some more work. > - dvds/vcds still don't work Tim just checked in his vcd support. > - thumbnailer is still broken Heh? works fine for me. > - firefox plugin still doesn't playback most formats Edward is going to add push mode support to ffmpeg. > - gnome-media's sound recorder still doesn't playback Works for me, got one non-critical error message, but a patch from Tim fixed that. > - for every cvs up of gstreamer, my totem (or any app) still takes >10s > to startup with no visual feedback Already replied to this one. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: requesting official list of modules and versions for GNOME 2.14
It is possible to run for instance 'gst-inspect-0.10' in the postinst script to force the registry rebuild. Christian On Fri, 2006-02-10 at 22:58 +0800, James Henstridge wrote: > Andy Wingo wrote: > > >There is no way to manually rebuild the registry in 0.10, so no more > >post-installation hooks are needed in distro packages. > > > > > I realise there is no need to manually rebuild the registry. I was just > wondering if there was a way for an administrator to rebuild the > registry (or a package postinst script), the same as is possible with > fontconfig. > > I'm wondering how many users would actually correlate the increased > startup time with the fact that they'd installed an OS update, rather > than considering the app to be unreliable. > > However, if the registration is fast in the general case, then it > probably isn't a problem. > > James. > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
On Wed, 2006-02-08 at 15:36 +1100, Jeff Waugh wrote: > > > > But it seems to me now that everyone other than me (and possibly Jono) is > > actually talking about Xgl, and I have no comment on that. > > > > (OTOH, if you really were saying that Novell's writing a replacement for > > the panel menu was "commons-sapping, community-tearing, morally and > > intellectually lazy", then by all means, let me know so I can write a > > suitably rude reply. :) > > I was not talking exclusively about Novell, Xgl, or the new panel applet. I > was talking about a serious problem in our community, and the destructive > ideas, memes and role models that support it. > Isn't what we got here exactly what has been asked for? That 'big' changes to GNOME needs to come from 'outside' projects? Havoc for instance was advocating that in his blog entries. So if people are unhappy about XYZ in GNOME, for instance the current panel. Due to it being so business critical we can't have experimentation going on in the gnome-panel CVS head, so 'radical' changes would need to be done as a separate project, and if it turns out good then it will at some point replace the current module. There is also a lot that gets thrown away, and I guess people don't want to spend time discussing UI and so on about something which might not ever get used outside their own machine, for instance someone mentioned the Novell Network applet, which afaik ended up in the dustbin and Novell started contributing to NetworkManager instead. That said I think the 'problem' of endless debates on desktop-devel in regards to actual development is overstated. 90% of endless debates on this list is not about module xyz, but about general policy issues like this one. If we want to get (back) to a situation where more gung-ho stuff happens in our core modules I think we need to do a couple of things. Like increase module maintainers freedom again (at the cost of the release team for instance) and accept that if radical changes happens to module XYZ the maintainer of that module is more free to ignore any criticism no matter who is giving it. So if the Nautilus maintainers decide that file manager windows should be circle shaped and not square for instance the rest of us have to accept that. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Hi, While it would be good to get fixes and improvements right away I do think its to hard to criticize anyone for holding back a bit on things they are doing. Being able to ship something first is an important marketing tool and this has happened before. In most cases where it has happened the distribution makers have been good at working with the community afterwards to get their changes merged upstream. Remember getting those changes merged in is in their interest too as keeping a larger and larger diff maintained is very costly and time consuming, so I am sure nobody wants to keep the changes any longer than necessary. Sincerely, Christian On Tue, 2006-02-07 at 14:41 +, Jamie McCracken wrote: > Luis Villa wrote: > > On 2/7/06, JP Rosevear <[EMAIL PROTECTED]> wrote: > >> On Tue, 2006-02-07 at 10:43 +, Jono Bacon wrote: > >>> Hi all, > >>> > >>> Just a quick question to anyone who may be in the know. After seeing > >>> the NLD10 videos, it seems the GNOME in there is rather similar to the > >>> mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/ > >> Indeed, these mockups were made internally at Novell by the UI team > >> (same guys that brought you betterdesktop). > >> > >>> I made a comparison in a blog post at > >>> http://www.jonobacon.org/viewcomments.php?id=637 to outline the point. > >>> > >>> Do we know if these radical changes to GNOME have been implemented, > >>> and if so, are the changes coming back to the community? > >> The changes that were implemented were not as radical as the mockups. > >> Basically what Nat F. showed in Paris is what was implemented. The code > >> will be released to the community soon. > > > > To ask the obvious question, why not now, and why not discussed > > publicly earlier? > > > > Ditto + do i take it the changes amount to a fork? (I assume as its > internal it does not have maintainer approval nor consensus?) > > To also be so blunt, is this a new strategy by Novell to keep new things > like these under wraps in order to steal a march on your competitors? > (if so I would be worried by this as it goes against the spirit of open > source where "open" is the definitive word - I would hate to see this > become common practice as if every gnome based organisation did this we > would end up in a mess as well as in the dark) > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Performance (wasRe: control-center 2.13.90 released)
Hi, Do we have a general performance problem currently? My Fedora Rawhide (FC5) desktop is slow as hell atm. I thought at first it was a distribution/development edition issue, but talking to people running Dapper at the office they are experiencing the same. One example, starting Totem for the first time takes about 30 seconds on my system now. Stopping and restarting totem multiple times lets me get that down to around 8-10 seconds. Christian On Tue, 2006-01-31 at 18:10 +0800, James Henstridge wrote: > Pat Suwalski wrote: > > >Elijah Newren wrote: > > > > > >>http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico > >>though in thinking we should make it fast instead. > >> > >> > > > >If memory serves, the background resampling and applying used to be very > >snappy and got significantly slower when everything moved to cairo. At > >this point, I have the X hashed background until a few seconds after my > >panels show up. > > > > > If this is the case, has anyone pinged Carl Worth about the slowdown, to > see if it can be fixed? (either on our end by doing the rendering in a > more efficient way, or by adding fast paths to Cairo for the particular > calls). > > James. > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
> Without any of this, people will just switch back to totem-xine or > other, non-GNOME apps like always, or just continue self-confirming that > Linux sucks. Very disappointing after my hard work to make GStreamer not > totally suck from an end user's point of view. Basically a total year > wasted. The is factually wrong Ronald, a lot/most of the great fixes you did last year are already in 0.10 and of those that are not still in it makes it much easier for us to fix similar issues in 0.10 when we can look at how you fixed them in 0.8. I know that Tim whenever he finds an issues verifies with 0.8 to see if it works there and then checks what fix was done there to see how to apply it to 0.10. I know this wasn't the solution you wanted, but please don't let it depress you into feeling the work you did is wasted, it is not, not even close. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
Hi Vincent, So the dual 0.8/0.10 thing for gnome-media has been discussed and our opinion was that we didn't want Tim to waste time working on a dual backend system when he already had a lot on his plate. Personally I think we should make 2.13 releases using 0.10. If the release team decide that they are worse than the 0.8 versions then the release team should just decide to use latest 2.12 release for 2.14 instead. If anyone ends up actually doing any work on the 0.8 version they are of course free to make new releases from the 2.12 branch. Christian > Answering myself to try to move the discussion here (instead of the > thread on release-team). Here's a more detailed "plan" I propose: > > + keep compatibility with both 0.8 and 0.10 in all of our modules > + push to fix regressions in 0.10 > + come back in ~1 month (on February 13th, when tarballs for 2.14.0 > Beta 2 are due) and look at what has been fixed and see if the worst > bugs reported against our modules are for GStreamer 0.8 or GStreamer > 0.10. > > I'm not sure, but I don't think there are features in the various > modules using GStreamer that *require* 0.10, are there? > > Vincent > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
On Mon, 2006-01-16 at 11:27 +, Bastien Nocera wrote: > The problem is that the stuff that used to work doesn't anymore. Well stuff that used to cause crashes in 0.8 doesn't anymore, so it goes both ways. > And there are over 80 opened bugs against the Totem GStreamer backend, > most of them should be either fixed in Totem, reassigned to GStreamer, > or put on NEEDINFO (against 20 for the xine-lib backend). Of those 80 most are from the 0.8 days. And they illustrate the problem with nobody working on the 0.8 stuff anymore. > > To me the big issue is not comparing the 0.8 vs 0.10 bug count, not that > > there is more bugs currently with 0.10, just different (and easier to > > fix), but which branch will see significant improvements and bugfixes > > going forward. 0.8 is not that branch and if we don't switch now, GNOME > > is stuck with a mostly dead 0.8 branch for the next 6-9 months. > > Currently the only thing happening in 0.8 is the applying of a few > > submitted patches, but no work is being done on the big hard issues, > > like improving the threading problems which causes all the random > > crashes people experience with 0.8 Totem for instance. > > Ronald filed about 10 GStreamer backend bugs in Totem. The progress on > those will be a good way to check on the progress for 2.14. Sure, Tim will be working on fixing these issues. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
Hi, Well Tim is working on just fixing Totem and gnome-media for 0.10 and will continue to do so for the next months at the minimum. Up to now his progress have been slow due to having to port over plugins for 0.8 as part of his porting effort, but now that this is mostly taken care of he can focus more fully on polishing and hooking up the few remaining features in Totem and gnome-media. I feel confident we will close the remaining regressions over the next month apart from some of the more obscure stuff (like computer game movie formats). There are also new stuff that will work with 0.10 which have never worked with 0.8 like Real format support and much improved MMS/WMA netradio support. To me the big issue is not comparing the 0.8 vs 0.10 bug count, not that there is more bugs currently with 0.10, just different (and easier to fix), but which branch will see significant improvements and bugfixes going forward. 0.8 is not that branch and if we don't switch now, GNOME is stuck with a mostly dead 0.8 branch for the next 6-9 months. Currently the only thing happening in 0.8 is the applying of a few submitted patches, but no work is being done on the big hard issues, like improving the threading problems which causes all the random crashes people experience with 0.8 Totem for instance. Christian On Mon, 2006-01-16 at 07:34 +0100, Vincent Untz wrote: > Le lundi 16 janvier 2006 à 07:28 +0100, Vincent Untz a écrit : > > It is possible to have both 0.8 and 0.10 installed at the same time, so > > the decision could be to ship both and have modules use 0.10 if it works > > for them and otherwise use 0.8. Or maybe support both with a configure > > switch. However, either of these would mean taking a lot of developer > > time that would seem much better spent fixing a single version. > > > > It is somewhat unfortunate, but the lateness of the issue will probably > > force some difficulty in the schedule. We may need to shove > > feature/module freeze effectively back a week (but not doing the same > > for subsequent dates) or being lenient with GStreamer-related freeze > > break requests at first to get this straightened out. > > My personal opinion is that we should keep the schedule as it is right > now, but accept some changes related to GStreamer so we can try to have > 0.10 for 2.14. If it doesn't work well enough (one month before the > big .0 release, eg), then we'll be able to go back to 0.8. > > Vincent > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Topaz discussion and the GNOME Project Desktop
Hi Jono, Most stuff so far is on the Wiki: http://live.gnome.org/ThreePointZero http://live.gnome.org/10x10 Christian On Thu, 2005-11-17 at 16:25 +, Jono Bacon wrote: > Hi all, > > I am not sure where is the best place to discuss Topaz? Is there a > specific mailing list. I just wanted to get peoples thoughts on > http://live.gnome.org/GnomeProjectDesktop > > Sorry if this is the wrong place to discuss this. > > Cheers, > > Jono > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Making GNOME crash
On Mon, 2005-11-07 at 15:17 +, Gustavo J. A. M. Carneiro wrote: > Seg, 2005-11-07 às 01:36 -0500, Matthias Clasen escreveu: > > On Sun, 2005-11-06 at 17:39 +0100, Vincent Untz wrote: > > > Hey, > > > > > > The next releases of glib (HEAD and glib-2-8) will support a new debug > > > flag for the G_DEBUG environment variable: fatal_criticals. This make > > > the program crash on critical warnings. > > > > > > I propose to use this nice feature during the development cycles to help > > > eradicate all these critical warnings. I made a simple patch for > > > gnome-session: > > > http://www.gnome.org/~vuntz/tmp/gnome-session.diff > > > > > > Why? Well, we currently have critical warnings in a lot of modules. And > > > we don't care since we don't notice them. With this, we could easily > > > notice them and have nice stack traces to fix them. This should result > > > in less bugs. > > > > > > Does it make the desktop unusable? Well, the wncklet-applet crashes [1], > > > it seems bug-buddy crashes on Fedora [2] and, err, I can't use > > > evolution ;-) More crashes are expected, but I think the sooner we fix > > > the critical warnings, the better. > > > > > > What do you think? > > > > > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=149326 with a patch > > > [2] http://bugzilla.gnome.org/show_bug.cgi?id=320062 > > > > > > Vincent > > > > > > > I'm not convinced that making HEAD unusable for everybody by enforcing > > this in gnome-session is the way forward. For one thing, it will > > drastically reduce the amount of testing that HEAD gets. I think making > > this the focus of a Gnome love day can have the same results without > > affecting the testability of HEAD for everybody else. > > I completely agree. This reminds me of some modules in the past > having hardcoded -Werror in CFLAGS. Some people just want to compile > and run GNOME, not be forced into fixing every module in the way. > Actually GStreamer do this, include -Werror, and it is in my opinion something which has worked out very well for us. Yes, it was a bit painful to get it working to begin with and it was a bit painful when gcc4 came out, but in general it means that we keep our code warning free, which I think has kept a lot of bugs from creeping in which would otherwise have been drowned in a sea of 'harmless' warnings. It isn't painful today as we catch new compile warnings right away, so fixing those isn't more painful than making sure your code follows module conventions and is acceptable in general. I don't know how this crash thing would turn out/work, but if it means we will have 3-4 painful weeks and after that have a GNOME with a lot of crasher bugs fixed then I am all for it. Cause after that new crashers will be caught as they are introduced which probably also is the time when its easy to fix them. (probably me being to naive though) Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Totem branched
I just knew you where a dedicated Delirium Tremens drinker :) On Wed, 2005-11-02 at 11:20 -0500, Ronald S. Bultje wrote: > Hi, > > I've branched off Totem 1.2 into the gnome-2-12 branch. Totem HEAD will > focus on GNOME 2.14 coolness, such as GStreamer 0.9 support and pink > elephants. > > Cheers, > Ronald > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mouse theme
Hi, I don't have any theme choices there, only change option I have is altering the size of the mouse cursor. I assume what Claessens have is something like the mouse themes in windows where you can have lots of really funky looking mouse pointers. If that is the case I think adding it to the theme manager is the right place as it is more about style than function. Christian On Tue, 2005-07-26 at 13:00 +0100, Calum Benson wrote: > On Tue, 2005-07-26 at 13:52 +0200, Claessens Xavier wrote: > > > I'm wondering why there is no interface in gnome-theme-manager to switch > > the mouse's theme ? > > It's in gnome-mouse-properties instead. Whether or not that's the right > place is another question, but nobody's complained so far. Maybe they > couldn't find it :) > > Cheeri, > Calum, > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: switching to g-c-c shell? [Was: Re: Control center and capplet merging]
On Wed, 2005-07-06 at 14:15 -0700, Sriram Ramkrishna wrote: > On Wed, Jul 06, 2005 at 03:31:58PM -0400, Havoc Pennington wrote: > > On Wed, 2005-07-06 at 19:37 +0200, Carlos Garnacho wrote: > > > Some may think that it could encourage people to add more capplets, but > > > that's already happening, in the last 2 releases we've added "Multimedia > > > systems selector", "Remote desktop" and "Removable drives and media", so > > > we should at least find a way for not punishing users because we don't > > > follow our own rules :) > > > > Right or we could just fix the problem - wait that would be INSANE ;-) > > > > If we can't get rid of at least "Multimedia systems selector" we sure do > > suck. > > You could porbably put multimedia systems selector stuff as gconf > keys and enable it there. The problem is that this stuff becomes > buried and for people who want to change it for whatever purpose > it becomes an egg hunt. Actually the multimedia systems selector is just adjusting gconf keys, so by just removing that GUI you would have the functionality of being able to override whatever the default is by changing the gconf key, but not having a GUI to do it. Another solution is to keep the selector around, but remove it from the gnome-menu. I guess the gstreamer viewpoint is that the auto*sinks will replace hardcoding to alsa/oss, x/xv and then people who have problems (like the free nvidia drivers failing to utilize xv if you have widescreen) can override it by hardcoding a sink with gconf-editor. (problem is that the driver still reports doing xv, so the auto*sink thinks it can use xv when it can't (all players I tried so far fail in figuring this out on their own, so I guess its not trivial to work around). I also guess powerusers would like to be able to tweak the keys manually if they for instance run 2-3 sound servers or have multiple soundcards. In which case an auto*sink plugin might not be able to guess correctly at what the user wants to happen. Christian > In these cases, it would be good to be able to find a way to get > access without too much trouble like a troubleshooter system that > tells you where to go if the default multimedia stuff doesn't work. > Taking a view of an undirected graph, all pieces of information > should connected. > > My two cents. > > sri > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 14:47 +0100, Mark McLoughlin wrote: > On Thu, 2005-06-09 at 19:00 -0400, Owen Taylor wrote: > > > - To be realistic, if GNOME-2.12 is released after GTK+-2.8, > > most distributors are going to ship using them together. > > > > So, the release team could decide to go with 2.6 even with > > the current GTK+ schedule, but the result then would be less > > testing of what people actually ship. > > Yeah, and that would significantly undermine the whole release process > IMHO. If the value of having GNOME releases is to have the very latest > GNOME technologies released as a stable, coherent and integrated set, > then by creating a situation where distributors go off for themselves > and figure out what *really* is the latest stable set of GNOME > technologies, we really reduce the relevance of GNOME releases. Well there are GNOME hackers working at all the major distributors who I am sure are able to inform the rest of their organization that going with GTK 2.8 would greatly increase the risk of bug and problems since it is not what the community have developed and tested with. If we believe that we can't influence the distributions on what they ship anyway, then maybe our whole release process is to be considered useless. I mean what is the point of doing GNOME releases if we assume nobody cares about how we compose our releases anyway. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
I guess a fair compromise would be to aim for using gtk 2.8 for 2.12, but not using any new functionality in gtk 2.8. That way if it turns out 2.8 is not stable enough we can roll back to 2.6 before release. On the other side it is stable enough then we ensure its gets widely distributed and tested so we can start taking advantage of it for 2.14. Christian On Wed, 2005-06-08 at 14:42 +0100, Andrew Sobala wrote: > On Wed, 2005-06-08 at 09:09 -0400, Luis Villa wrote: > > So, yeah, I'm pretty strongly against this, though I'm open to persuasion. > > Me too, for all the reasons Luis listed. I remember our r-t > discussions basically concluded that we'd made a mistake depending on > GTK+ for 2.6. 2.6 had stability issues. > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Revitalizing the Urban Center of GNOME
Hi Mark, On Thu, 2005-02-17 at 14:46 +, Mark McLoughlin wrote: > Hi Christian, > > On Thu, 2005-02-17 at 13:56 +0100, Christian Fredrik Kalager Schaller wrote: > > What would help the problem a lot is if debates go more into specific > > sublists instead of going onto desktop-devel. One of the main reasons > > for this is that for many sub-projects the relevant maintainers are not > > on the relevant lists. I find it kinda pathetic for instance that > > someone who proclaims himself Lord of the Theme is either not subscribed > > to or at least have never posted to the gnome-themes list, and through > > that is forcing theme discussions onto desktop-devel. Similar problems > > for other sub-projects, which together collate into desktop-devel > > getting flooded. > > That's a given, but I do find it understandable that when a list > becomes as dead as gnome-themes-list is, people naturally move away from > using it. Part of fixing the desktop-devel-list problem should involve > re-vitalising those other lists, but ... Why is this understandable? The volume on librsvg-devel is about maybe 2 mails a month. That doesn't mean that Caleb and Dom either not stay subscribed or ignore messages on it. > > Maintainers actually being part of the subproject they pretend to > > maintain instead of screaming murder on 'global' lists would do more > > for this problem I think than lots of 'shut up' messages sent to > > desktop-devel or gnome-hackers. > > ... lets not kid ourselves - we don't want to just split up the volume > of mail amongst many lists, we want to solve the social problems that > make it difficult for hackers to have clear lines of communication. Splitting the volume would mostly solve the problem as each of us would not get all messages on all topics. Just the messages relating to the topics we are subscribed too. Maybe some subtopic's still needs people showing mailing restraint, but that it not so easy to judge before the mails actually go to relevant lists. > To give an analogy - if this was a BOF at GUADEC, we started talking > about themes and everyone started shouting their opinion, it wouldn't be > long before someone stood up an shut the thing down. That person > wouldn't tell everyone who wanted to talk about themes to go to another > room. He'd either gather the stakeholders together in the hallway and > have the discussion or make it very clear that people need to restrain > themselves. Can't see how this analogy is analogical of anything related to this discussion. The problem is not the themes BOF discussing themes, its about discussing themes (and other topics) in the BOF meant for discussing cross-module cooperation. If we look at the separate topics being discussed on desktop-devel, I think that if we look at the issue over a year there is no topic that is 'overdiscussed', the problem is that they tend to 'all' get discussed on desktop-devel undermining the real purpose of desktop devel. > (Also, its not hard to see that its really Seth's "I am Lord of the > Theme" mail that you have a problem with here - better to just sort that > issue out than clouding this one.) No, its more Seth providing me with a perfect example of why we have these problems through his actions. Anyway I have stated my opinion on this subject and will leave it at this. Think I have made my point, and if I haven't I probably will continue failing to do so by further mails. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Revitalizing the Urban Center of GNOME
What would help the problem a lot is if debates go more into specific sublists instead of going onto desktop-devel. One of the main reasons for this is that for many sub-projects the relevant maintainers are not on the relevant lists. I find it kinda pathetic for instance that someone who proclaims himself Lord of the Theme is either not subscribed to or at least have never posted to the gnome-themes list, and through that is forcing theme discussions onto desktop-devel. Similar problems for other sub-projects, which together collate into desktop-devel getting flooded. Maintainers actually being part of the subproject they pretend to maintain instead of screaming murder on 'global' lists would do more for this problem I think than lots of 'shut up' messages sent to desktop- devel or gnome-hackers. Christian On Thu, 2005-02-17 at 00:09 -0500, Seth Nickell wrote: > >You have every right to ask for an off-topic discussion to go off > list, > > but you have no right to recommend people not reply to him, and you have > > no right to say the way he wants to make a proposal is "useless". Its > > his time to use as he pleases. > > > > If he puts forth something that looks like "dogs breakfast", then you > > can dismiss it on more valid grounds than that you personally don't like > > his methodology. Some people work differently than you Jeff. You should > > find more constructive ways of deal with them then telling them to shove > > off. > > Jeff was certainly curt, and perhaps should have been gentler in making > the point, but he's probably right too. In his judgment (and mine too, > fwiw) that thread was doomed to produce very little impact, a lot of > noise. > > Something GNOME enthusiasts on this list often seem to forget is that > its *not* just their time. When you send a message to a mailing list, > you are asking for everyone to spend some time on it. When you start a > thread that will draw lots of replies, you are, unwittingly or not, > asking for everyone on the list (including hackers) to spend lots of > time. > > I define the GNOME enthusiast community as: those who are actively > involved with and interested in GNOME but have NOT contributed large > quantities of code, translation or documentation (there are several > exceptional cases, for example Jeff himself, but not a lot). We need > enthusiasts and should value them! It provides a source of excitement, > sociability, feedback on how we're doing in different areas, and > sometimes even new ideas. > > But right now, the lists have become driven by the enthusiast community > to the extent that hackers have gone into hiding. A good thread on > desktop-devel-list *should* be predominantly (75% or more, say, as a > totally arbitrary number) posts by core GNOME hackers related to that > area. Look at a thread now probably 90% of the posts are by > enthusiasts. That's taking "being in touch with the community" a little > too far to the point that its hard to get work done ;-) > > For example, most of the people actually writing code that will be in > the next GNOME release have probably been actively deleting every > message to this theme thread! Its not because they don't care, its > because they don't want to take the time away from working on gnome to > wade through all the noise. And they shouldn't have to. > > Compared to its peak as a lively discourse among the hackers doing core > contributions to the gnome codebase, desktop-devel-list is almost a dead > list in terms of "useful things accomplished". Part of the problem is a > *very* high noise level, and also very annoying persistent threads of > the bike shed variety. > > Something people only relatively recently involved in GNOME (last couple > years) wonder is about the relative silence / non-responsiveness of core > hackers. It seems like desktop-devel-list, despite all the traffic, has > very few people who are getting something done (see usability@gnome.org > for an even worse example of this that is even more my fault). That the > lists we (core hackers) used to haunt have become a tangle of weeds is > one of the major factors driving this. > > As community leaders in GNOME, one of our jobs is to shepherd the lists > so they do not become exceedingly noisy (and scare away important hacker > to hacker traffic). But we have largely abdicated this responsibility in > the last couple years. markmc tried to fight the tide about a year ago, > but eventually gave up. Its hard *because* we're actually very nice > people, and thus none of us want to be the list nazi. But its also very > important to have this sort of pruning to be a healthy community. > > We've been talking about this a lot lately in s33kret cabal discussions. > That we feel the need to have these private circles is part of the > problem! Nobody, even those of us involved in the cabal (and especially > not Jeff who is an outspoken supporter of openness and inclusion), want > this sort of private exclusionary
Re: Exciting GNOME?
Nuvola is today in gnome-themes-extras. I am going to move it into gnome-themes if the maintainers of that package approve the move and make a new final release of g-t-e without Nuvola. This means that while it will not be the default theme for GNOME it will be part of a default installation. http://librsvg.sourceforge.net/theme.php shows how the metatheme currently look. Christian On Tue, 2005-02-15 at 19:23 -0200, Everaldo Canuto wrote: > Look at this: > http://www.kde-look.org/content/show.php?content=5358 > > A nice icon theme. Colors and Life > > Everaldo. > > Em Ter, 2005-02-15 Ãs 19:09 -0200, Everaldo Canuto escreveu: > > Yes... it is nice and clean... but where is "life" and "color"? > > "Clean" is good when your work 8 or more hours on a computer but if you > > user 1 hour per day to read your mail "Clean" sounds like a "Ugly". > > > > I like "etiquette" but now is time to thinking like a "END USER". Or > > GNOME and Linux always is for "hackers"... The KDE team is on another > > way, the way for "end users"... and GNOME? > > > > Everaldo. > > > > Em Ter, 2005-02-15 Ãs 21:57 +0100, MichaÃl Arnauts escreveu: > > > I think the new etiquette icon theme is quite attractive... It's still > > > clean like the default Gnome one, but it has a refreshing new look... > > > Especially the mime-types... I love it... > > > > > > http://www.gnome-look.org/content/show.php?content=19853 > > > > > > > > > On Tue, 15 Feb 2005 18:06:17 -0200, Everaldo Canuto > > > <[EMAIL PROTECTED]> wrote: > > > > ClearLooks is really nice but now we need a more atractive icon set. > > > > > > > > Everaldo. > > > > > > > > Em Ter, 2005-02-15 Ãs 17:53 -0200, Everaldo Canuto escreveu: > > > > > This CleanLooks is nice but I dont like menus... I think that menu > > > > > need > > > > > to be same aspect at tool bar like original BlueCurve. > > > > > > > > > > Everaldo. > > > > > > > > > > Em Ter, 2005-02-15 Ãs 19:52 +0100, Daniel Borgmann escreveu: > > > > > > On Tue, 2005-02-15 at 12:13 -0500, Pat Suwalski wrote: > > > > > > >Gabriel Bauman wrote: > > > > > > >> Most folks I know install GNOME, shudder, then install Bluecurve > > > > > > >> and > > > > > > >> never look back. > > > > > > >> > > > > > > >> Is it a Red Hat licensing issue perhaps? > > > > > > > > > > > > > >I would say it's a little more than that. Bluecurve is what > > > > > > >identifies > > > > > > >RedHat. I don't think that it would be appropriate to use it, > > > > > > >legally > > > > > > >possible or not. The same applies to Ximian/Novell and Industrial. > > > > > > > > > > > > Well, did you take a look at Clearlooks[1]? Someone mentioned it at > > > > > > the > > > > > > Wiki[2], I tried it and it totally blew me away! It's based on > > > > > > Bluecurve, but got more modern and fresh looks. It hardly looks like > > > > > > Bluecurve anymore, besides some pixmaps and the menus. The author is > > > > > > also very actively working on it and preparing a website including a > > > > > > voting booth. The next version will have properly rounded > > > > > > scrollbars[3] > > > > > > and some other improvements, for example he's looking into > > > > > > improving the > > > > > > comboboxes, which traditionally look a bit like a mess[4] in Gtk. > > > > > > It might sound overzealous, but my honest opinion is that this > > > > > > engine > > > > > > simply smokes the competition (including Plastik, which is very > > > > > > popular > > > > > > for good reason), the author is independent of any commercial > > > > > > vendor and > > > > > > it's still rather new, so not many people know about it yet. What > > > > > > could > > > > > > be better suited? > > > > > > > > > > > > > > > > > > [1] http://gnome-look.org/content/show.php?content=19527 > > > > > > [2] http://live.gnome.org/NewDefaultTheme > > > > > > [3] http://www.stellingwerff.com/headers.png (notice that > > > > > > Clearlooks has > > > > > > many color schemes already, that's just one of them) > > > > > > [4] I made this mockup to demonstrate the problem: > > > > > > http://213.133.111.182/Temp/ComboBoxEntry.png > > > > > > > > > > > > > > > > > > > > > ___ > > > > > desktop-devel-list mailing list > > > > > desktop-devel-list@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > > > > > ___ > > > > desktop-devel-list mailing list > > > > desktop-devel-list@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > > > > > > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ deskto
Re: Solution suggestion [Was: gtk-engines photographed eating children]
I thought the whole point of having gtk-engines with all these engines includes was to have one maintained module with everything included. If its to just be a 'meta-module' with code dumped in from other places I honestly do not see the point of it at all. I mean if you don't even want smooth having this package as its home then that says a lot in my opinion. Also could we end this thread. Either up the version to 2.10 or let Jeff figure out how to solve his fucked up packaging on his own. He can claim until he is blue that the debian packaging of the engines was sane, although everyone else considers it not to be, so all that is left is for either you to release gtk-engines 2.10 or ignore his cries. Or ditch the whole gtk-engines module into the sea if my impression as listed in the first paragraph is correct. Christian On Tue, 2005-01-25 at 00:54 -0500, Andrew Johnson wrote: > I did some looking and Mist has been mostly complete since 0.10, which > was the last standalone release almost two years ago. What was in > gnome-themes was that plus a few minor fixes by Dave Camp himself. So I > expect that it will be for the most part primarily maintained in > gtk-engines, the only issue is it also has a gtk1 engine, but I don't > see any other development on it so its last release may have been 0.10 > in which case its not an issue anyway. I would count the latest version > as 0.11 I suppose to differentiate. > > LighthouseBlue has been maintained on SF by the author, and has both > gtk1 and gtk2 engines which share portions of the same code base. It is > feasible there will be future releases of it, though we would have to > find out. If the gtk1 engine is no longer maintained it might be trivial > to make gtk-engines its future home. It's version is at 0.7(I knew one > of them was 0.7, I just got it mixed up). > > ThinIce has not seen any development outside of gnome-themes in about > two years, so it seems quite likely its primary home would be > gtk-engines now anyway. It did a 2.0+ version bump itself when it ported > to gtk 2.0, and did few patch releases. Since being in gnome-themes > there have been some bug fixes, but again only minor, so adding another > patch version I would count the thinice in gtk-engines as 2.0.4. > > Crux hasn't been maintained at all really, it was ported from the > original version by Seth and dumped into gnome-themes and hasn't been > touched much since for anything, so having it maintained in gtk-engines > won't be an issue. and having it keep the arbitrary version number of > 2.10 onward makes little difference. > > HC has as far as I can tell only every been maintained in gnome-themes, > so again 2.10 is as likely a version number as any. > > Industrial, has traditionally been maintained by Ximian now Novell as > part of the artwork, but there has been talk recently of putting it in > gnome cvs, so if we can make sure that gtk-engines is where it stays > there shouldn't be any issues there UNLESS they wish to continue to > develop the gtk1 engine in sync with it. Because it was never maintained > seperately I believe its version is effectively that of the latest > Ximian/Novell Artwork since it was never officially a standalone module. > > Smooth has been maintained and for now will continue to be maintained on > SF, it is in gtk-engines only too get it out of gnome-themes and > gnome-themes-extras not because I want to maintain it there. I will > continue to keep it in sync with the latest stable release + bug fixes > but generally speaking it only complicates things. It has its own > version which it will continue to keep, and I hope gets followed, right > now it is at 0.6, with a quick bug fix release of 0.6.0.1 going to be > released once I get a chance. > > Redmond and Metal have only ever been maintained in gtk-engines in at > least the gtk 2.x lifespan and probably a lot longer. They are > > Andrew > > On Tue, 2005-01-25 at 16:10 +1100, Jeff Waugh wrote: > > > > > > > Each gtk engine has its own version > > > > > Mist is what, at 0.7? This wouldn't have changed anything from that > > > perspective except maybe a patch number on the package... > > > > So, addressing the suggestion to use the engine versions - there is no clear > > documentation of individual engine versions in gtk-engines, so it's not > > surprising that there are packages of crux at version 2.9.x, for instance. > > > > Regardless of issues peculiar to distribution packaging, the aggregation of > > engines that are not clearly maintained primarily in gtk-engines is cause > > for some confusion. Should distros/users choose industrial from gtk-engines > > (version 2.6.0) or from wherever else it's maintained and released (version > > 0.2.36.4)? > > > > The problematic engines in this regard appear to be industrial and smooth, > > but potentially lighthouseblue, mist and thinice - are they now maintained > > in > > gtk-engines only? > > > > As long as we have absolute clarity on th
Re: gtk-engines photographed eating children
On Tue, 2005-01-25 at 04:14 +1100, Jeff Waugh wrote: > Regardless of the fact that you've now reduced the only version number that > matters (upstream source tarball version) of these theme engines? I don't understand the versioning argument. AFAIK so has there never been a release of gtk-engines width a higher version number than the current one (which if there has been would be a problem). The version number of gnome-themes which I sometime skimming this thread get a feeling you are comparing the gtk-engines version number with is not really relevant IMHO. What needs to be done is a) make sure the SPEC file (or .deb definition) of gnome-themes relies on a new enough version of gtk-engines (one that have all the engines that used to be in gtk- engines). The gtk-engines package needs to be marked as conflicting with gnome-themes package below this version number. This way when you apt-get upgrade either the gtk-engines or the gnome- themes package you get a compatible versions of both packages installed. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
