Re: Pulseaudio

2007-10-17 Thread Thomas Vander Stichele
 Asking for hw mixing in PA is like asking
 for support for MPEG decoder cards in GST.

GStreamer actually has support for dxr3 cards :)

My sound cards at home all have hardware mixing; it's in my experience
only embedded sound cards (laptops, dell boards, the crap-in-many-ways
ICH series...) that only have one hardware channel.

My 2 cents,

Thomas


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Why have a ChangeLog file if you already have commit messages?

2007-09-17 Thread Thomas Vander Stichele
On Sun, 2007-09-16 at 00:13 +0200, Jaap Haitsma wrote:
 Hi
 
 Talking to Daniel Cheese Siegel we asked ourselves:
 Why do all GNOME projects have a ChangeLog file?
 Isn't it redundant when you just save a commit message.

Because they communicate at different levels.

I have yet to see a project that has clear, concise commit messages, and
all the commits are well-defined, atomic, and no screwups.

The number of commit messages that go fixed stupid typo or I was
drunk when I commited this make a commit message log unsuitable as a
candidate for a ChangeLog.

When I'm reading a ChangeLog, I want to know what changed in the
software overall; what changes the developers are making, and why they
are making them.  I don't want to read about every single small detail
they changed while making those changes.

When I'm reading a commit log, I typically figure out what the hell a
developer was thinking when he introduced a bug or did something silly.

Just my 2 cents,
Thomas


-- 
And every time she sneezes
I think it's love and oh lord
I'm not ready for this sort of thing
--
MOAP - Maintaining your projects since 2006
https://apestaart.org/moap/trac/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: [gst-devel] Why is gstreamer not an external dependency?

2007-05-22 Thread Thomas Vander Stichele
  
  Definitely a good question to mull over.  I don't have a good answer.
  Maybe someone else does.
 
 Well, to me, it makes totally sense to have a multimedia framework in
 GNOME since many applications are dealing with multimedia.
 
 I believe the goal is to move GStreamer to the platform once it becomes
 API-stable.

For all intents and purposes, GStreamer *is* API-stable.  You will
always have an API-stable GStreamer 0.10 to link against.  If 0.12 or
1.0 comes out, even if the API doesn't change, configure.ac files need
to be updated to find it.  0.10 will happily coexist with 0.12 and 1.0

  Btw, it'd be really nice to know if there are plans to
 release GStreamer 1.0 ;-)

There are always plans.  Not speaking for anyone else on the GStreamer
team - my personal feeling is that we should have apps like Jokosher and
Pitivi and Flumotion and a DVD player running happily, do one short
iteration of 0.11 where we clean up the worst bits of the API that we
don't want to support, and implement some more advanced features like
interlacing, and then it's ready to go.  But this is just a personal
opinion...

Thomas


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: [gst-devel] Why is gstreamer not an external dependency?

2007-05-22 Thread Thomas Vander Stichele
On Tue, 2007-05-22 at 23:26 +0800, James Henstridge wrote:
 On 22/05/07, Thomas Vander Stichele [EMAIL PROTECTED] wrote:
  Hi,
 
   If you don't break the API in the next series, why would you make a
   change that requires every application to be updated to take advantage
   of the new release?  Doesn't that just make work for everyone?
 
  The applications don't need updating, the configure.ac
 
  For some reason people *want* to see a GStreamer with the numbers 1 and
  0.  So they will want to use a gstreamer-1.0.pc file.
 
 Okay.  In that case, you could include a symlink from gstreamer-1.0.pc
 - gstreamer-0.10.pc, and have all the old applications continue to
 build correctly and have a new version number in the pkg-config
 package name, right?
 
 It just seems crazy to break compatibility for something as small as this.

Sure, lots of stuff possible.  I don't *expect* them to be fully
compatible however, since I'm sure there will be API warts that get
cleaned up.

Thomas


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Mono/GTK#/Tomboy

2006-07-14 Thread Thomas Vander Stichele
Hi,

 Further, the objections mentioned all seem to apply equaly to python and 
 mono. Python is allowed for desktop apps already. If nobody can come up 
 with objections to mono that don't apply equally to python, it would seem 
 that mono and python should be on equal footing.

I don't think that is true; if that were true, any language that
satisfies the same basic requirements would be acceptable.  Clearly it
is not ideal at all to have five different runtimes side by side all
eating memory in their own way.

Python was the first language to reach enough maturity and ruffle the
least amount of feathers, and that is a point of differentiation with
any language that comes in later.

The important thing we wanted when Python got accepted was to have at
least one higher-level language to be available for use, and not have a
lot of them.

So in short, I don't think there is an equal footing, and if people
would want Mono in, it should replace Python, not sit side by side to
it.

Thomas

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Mono/GTK#/Tomboy

2006-07-14 Thread Thomas Vander Stichele
Hi Miguel,


 Today the issue of resource usage is brought up as if it were the end of
 the world, back in the day, Jonathan made the following comment:

To me it's not the resource usage of any such language as such on its
own. I'm living under the delusion (for the sake of argument) that a
python app and a mono app are comparable in their resource usage.

 I do not think there should be only one way of building applications
 for Gnome.  We would not have the official language bindings release if
 we thought that only C code was worth having.

I think any language is fine for writing a Gnome app.  The issue is more
about what is officially put in a Gnome desktop release as such - how
many managed languages with their own runtime do we want as part of a
default Gnome desktop ?

Thomas


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Intellectual Property Plugins and GNOME

2006-06-16 Thread Thomas Vander Stichele
Hi,

 On Wed, Jun 14, 2006 at 03:43:49PM -0400, Ronald S. Bultje wrote:
  On Tue, 13 Jun 2006 15:26:59 -0500, Brian Cameron wrote:
   Here at Sun, we have been talking with Fluendo about licensing these
   plugins.  As you can imagine, it is fairly expensive to acquire a
   license that allows a vendor to freely ship these plugins (as opposed
   to a per-use license).
  [..]
   Perhaps Microsoft and Fluendo would find it interesting to work a
   license with the GNOME community
  
  Such a license would violate any of the ideals that we stand for.
 
 Ronald is correct, it would violate the Free as in Freedom.  However,
 you should be taking this to the distributions rather than the GNOME
 community itself.  Distributors and perhaps user's themselves could 
 license it.

Where is the start of this thread ? Nobody I've asked seems to have
anything before Ronald's mail.

Thomas


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Intellectual Property Plugins and GNOME

2006-06-16 Thread Thomas Vander Stichele
On Wed, 2006-06-14 at 15:43 -0400, Ronald S. Bultje wrote:
 On Tue, 13 Jun 2006 15:26:59 -0500, Brian Cameron wrote:
  Here at Sun, we have been talking with Fluendo about licensing these
  plugins.  As you can imagine, it is fairly expensive to acquire a
  license that allows a vendor to freely ship these plugins (as opposed
  to a per-use license).
 [..]
  Perhaps Microsoft and Fluendo would find it interesting to work a
  license with the GNOME community
 
 Such a license would violate any of the ideals that we stand for.

I agree with Ronald (though violate is overstating it :)) that this
should not be done by the GNOME foundation as such.  It would make sense
for a group of distributions to team up in some form to do this - but
the GNOME Foundation should be about Free Software.

(For those of you like me that didn't get Brian's original mail - he was
asking what people think about the possibility of some distributors
giving money to the GNOME foundation so that the GNOME foundation could
pay the license fees for proprietary codecs)

Thomas


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: gstreamer-0.10.x tarballs on f.g.o: checksums differ from those on freedesktop.org

2006-05-22 Thread Thomas Vander Stichele
On Thu, 2006-05-18 at 21:10 +0800, James Henstridge wrote:
 On 5/18/06, Joseph E. Sacco, Ph.D. [EMAIL PROTECTED] wrote:
  The checksums for the gstreamer-0.10.x tarballs on ftp.gnome.org differ
  from those on http://gstreamer.freedesktop.org/src/gstreamer/
 
  How can that be?
 
 The install-module script used to add things to ftp.gnome.org takes
 a .tar.gz archive, puts it in the right place, and creates a matching
 bzip2 archive.

It'd be nice if the install-module script would prefer using an already
uploaded bz2 instead of recreating.  Would a patch for that be
accepted ?

Thomas


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: intltool 0.35.0

2006-05-18 Thread Thomas Vander Stichele
On Mon, 2006-05-15 at 12:59 -0400, Rodney Dawes wrote:
 On Mon, 2006-05-15 at 18:32 +0200, Murray Cumming wrote:
  On Mon, 2006-05-15 at 12:23 -0400, Rodney Dawes wrote:
   I just released intltool 0.35.0 to the world. It includes a number of
   bug fixes, as well as the famed LINGUAS support.
   
   If your project uses the po/LINGUAS file, please specify at least 0.35.0
   as the required version in your configure.{in,ac} file.
  
  How?
 
 IT_PROG_INTLTOOL([0.35.0]). The projects should already be requriing
 0.34.90 anyway, and just need to bump this number.

Projects that have their own autogen.sh and don't hook into
gnome-autogen.sh, but copied previous code, that scans for
AC_PROG_INTLTOOL to decide whether to run intltoolize, should also fix
their autogen to grep for IT_PROG_INTLTOOL.

I'm sure there was a reason for renaming that macro.

Thomas


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: desktop-devel-list Digest, Vol 23, Issue 9

2006-03-09 Thread Thomas Vander Stichele
On Wed, 2006-03-08 at 08:38 -0500, Ronald S. Bultje wrote:
 On Tue, 07 Mar 2006 19:50:17 +0100, Thomas Vander Stichele wrote:
  However, not everyone in the GNOME community necessarily agrees with
  this.  I got *a lot* of requests to add an mp3 recording profile to
  gnome-media.  Historically, I've always refuted these requests because I
  agree that GNOME should not be endorsing them.
 
 You're confusing user choice with accepting and confirming validity of
 corporate patent portofolios.

I was talking about neither one of those - so how can I be confusing
them ?

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
ik kon liegen
ik kon jou bedriegen
mezelf verraden
zonder spijt
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: release notes: first draft

2006-03-07 Thread Thomas Vander Stichele
Hi,

  plugins are not available. The GNOME 2.14 distribution does not itself
  contain these non-free components.
 
 Actually better yet
 
 contain or endorse

I'd be completely fine with this standpoint.

However, not everyone in the GNOME community necessarily agrees with
this.  I got *a lot* of requests to add an mp3 recording profile to
gnome-media.  Historically, I've always refuted these requests because I
agree that GNOME should not be endorsing them.

But the dam might crack at some point :)

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
Put something real to me
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
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

2006-02-12 Thread Thomas Vander Stichele
Hi,

 - subtitles embedded in movies (.mkv, .ogm, dvds) still don't work
 - language selection (audio tracks, subtitles) still doesn't work
 - dvds/vcds still don't work

I have the feeling that in your mails a too rosy picture of 0.8 is
painted.  I don't particularly like looking for and uncovering some of
the dinky parts of GStreamer, but I don't think it's fair to
continuously compare 0.10 and 0.8 only by a bullet list, and not on the
quality of the particular bullet item.

So, for comparison, I tried doing something on 0.8 that you keep
claiming works fine: DVD playback.

I used my 3GHz hyperthreaded home machine - my laptop has a crappy DVD
drive that can't even play most dvd's I have.

DVD 1: Aardvark'd

+ choosing audio language works
- subtitles are enabled unconditionally.  There is no way to turn them
off from the menu (it says no subtitle selection available).
- subtitle shadows bleed over the rest of the image (see
http://thomas.apestaart.org/download/tmp/totem-subtitle.png; I switched
to ximagesink to make the screenshot)
- there's no way to go back to the main menu (nothing happens when
choosing options from the Go menu)
- seeking messes up the synchronization; after a seek, the audio is
easily a second off from video (using osssink or alsasink)
- during playback, audio repeatedly stutters in very short bursts;
probably related to the A/V desync
- I did one run where I did not seek at all, just let it play from the
start - A/V was also not in sync already after 90 seconds
- sometimes seeking doesn't do anything at all, period.  I drag and
release the slider, and nothing happens.  No seek, no time update,
nothing.
- while playing it uses 70% CPU and above (using xvimagesink).  Overall
playback is jerky, definately not as smooth as other players.
- during some runs, the initial boondoggle logo section at the start
of the disc starts slowing down to a crawl at the end, then takes half a
minute to complete and go to the menu
+ clicking on items in the menu works in the sense that it moves on to
the movie ...
- ... but it didn't actually do what the option said; for example I
chose a different audio track from the menu, and I had the main one.  I
could still choose a different audio track from the menu though.
- during playback, I regularly get criticals; assertions about caps
changes that failed and gst_tag_list assertions
- I've had a few Internal GStreamer error messages pop up during
playback; surprisingly, the DVD continued playing just fine :)
- two times, after a seek, it started consuming all my memory and sent
my machine in a swap storm, finally killing totem.

All in all, it's not even watchable if you just pop in the disc and tell
it to play, without doing anything special.


I tried some other DVD's as well:
- Much ado about nothing: plays the MGM intro (thougn not
deinterlaced), then at the end freezes, waits five seconds, pops up an
Internal GStreamer error dialog, and then renders the first screen of
the menu.  Nothing in the menu works, play does not work, and there's no
way to start the movie.

- Chasing Amy: strangely enough, this presented me with the file
chooser dialog when picking Play Disc.  Mplayer plays it fine as a
dvd.  Probably not a GStreamer bug, but something lower down the stack.

- meeting people is easy: annoyingly, this dvd has a 43 second
warning section as the first section.  Amusingly, the position
indicator was jumping back and forth all the time while playing.  At the
end of the section, again the last frew frames slowed to a crawl
completely until they faded out to black, and then I got the menu.  No
error dialog, so good.  I could pick play from the menu, and playing
worked.  First seek made the movie stutter.  Movie is not deinterlaced.
Not in sync either.

- Pixies: does not even start at all.Clicking play again throws a
bunch of criticals about invalid casts, then segfaults.  Mplayer plays
it.  This is a DVD without menus, as far as I can tell, but with several
tracks.

- The office series 1: starts, plays the 20 second author organisation
clip.  Second clip is the age guideline clip, which is scrambled until
halfway through.  Third clip is the BBC one.  After this, a GStreamer
dialog pops up, together with an initial frame from the menu.  After
that, nothing works anymore.

These six DVD's were taken from the top of my DVD pile; they all play
fine on my Playstation (my main DVD watching machine).  Overall, my
experience seems to match the experiences from other people out there
from a quick google on totem gstreamer DVD  So final score is two
halves out of six - not enough to make it a bullet point pro gstreamer
0.8, I think.

As has been said before in related threads - the DVD support was added
late in the GNOME 2.12 cycle and with clear disclaimers.  Since then,
very little work has been done on it in the 0.8 branch.  I don't expect
much more work to be done there - you're currently the only person doing
any work on the 0.8 branch, and you said 

Re: Design by Community

2006-02-08 Thread Thomas Vander Stichele
Hi,


   I know some very wise people have decided, apparently without much
 discussion with the community, that GNOME would switch to Subversion.
 But I keep thinking that, although Subversion is much better than CVS,
 maybe we would benefit more from a distributed version control system,
 like mercurial, bzr, git, monotone, etc.

One of the drawbacks of these distributed version control systems is
precisely the fact that it makes it very easy to keep private branches
around.

All things equal, it would work against the goal of trying to make sure
development happens in public.

That's probably a very good reason why subversion may be the best choice
for GNOME at this point.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
nobody's interested
in something you didn't do
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
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

2006-01-22 Thread Thomas Vander Stichele
Hi,

 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.

As Christian is saying, you're painting a too bleak picture.  We've all
invested in 0.8, both us as community members and some of us as
employees of Fluendo.  So have you, both in your spare time as well as
paid by Fluendo.  None of your work is wasted - all of it is already
being used already or waiting to be ported over.  Every single element
that gets ported to 0.10 gets started from the 0.8 version.

Also, let's not overstate the problems in 0.10.  It's pretty clear that
a lot of formats are easier to fix in 0.10.

With Julien's fixing on Totem this weekend as well as some other fixes
all over, I've been able to play .avi files, divx files, mpeg-4 video
files (apparently a bunch of quicktime fixes went in), and all of them
have a lot better and more responsive seeking than the 0.8 versions ever
had.

Also, 0.10 handles aspect ratio better than 0.8 did - try playing
starwars.mkv in the 0.8 and 0.10 version, it's a particularly hairy file
to test with.  Unless Nathalie Portman is in fact so stick thin that she
needs to go see a psychiatrist for her eating disorder, this is just one
of the cases where the 0.10 version is simply better than 0.8

All of the file tests I did were done with only the GStreamer modules,
no Fluendo-specific modules in there.

The only major formats that I have files for that do not work at all yet
are .asf and .wmv files.  And the only real issues I had with current
files were with some .vob files (not all of them) - which also seem a
lot better with the freely available Fluendo MPEG demuxer.

I hope people will try out the 0.10 version of totem and give us some
feedback on what works.  If you haven't seen the seeking yet, you should
- it's zippy.  Scrub that drag handle to and fro.  You know you want
to !

Happy hacking,

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
I've got ladyfingers baby
I've got kidgloves
baby I got heart
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
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

2006-01-17 Thread Thomas Vander Stichele
Hi,

  
  Is GNOME 2.10 maintained?
 
 If you want to do an analogy, you should ask : is GNOME 2.12
 maintained ? ;)

No - since GNOME 2.14 is not out yet.

The question is - is GNOME maintaining more than one stable branch at
any point ?

 After discussing on irc, it seems not everybody has the same definition
 of unmaintained.
 
 For me, unmaintained means dead, ie no more commit on CVS, nothing.

I think in this particular case, for me it means something roughly like:
- important security fixes will get applied and released
- crasher bugs that have patches and are not invasive will get applied
- I make an effort to not destabilize the latest released version on
this branch by applying random patches from wherever without proper
testing
- I'm not actively looking for bugs to fix in it
- big feature additions, addition of plug-ins, ... do not get applied

I think that's a fair compromise between work involved, viability of
that branch, and expectations from users of that version.


I am assuming that Ronald, by maintaining, in this case, means he might
try and fix bugs on his own.  In practice, given that he's busy, I would
expect him to either be really annoyed by it personally or have a patch
in bugzilla to work from.


My only worry when it comes to 0.8 is possible destabilization of a
highly evolved code base that is about as good as it can possibly get at
this point.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
Kiss me please kiss me
Kiss me out of desire baby not consolation
Oh you know it makes me so angry cause I know that in time
I'll only make you cry
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
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

2006-01-16 Thread Thomas Vander Stichele
Hi,

  
  Of those 80 most are from the 0.8 days. And they illustrate the problem
  with nobody working on the 0.8 stuff anymore.
 
 So, can we hope that some of you (Tim?)

Let's not shovel too much dirt on Tim yet :) We're already passing him
all of the hot potatoes.  Tim's focusing on the 0.10 bits.

  will triage those bugs soon?
 Because for me, it doesn't illustrate the problem that nobody's working
 on 0.8 but it does illustrate that nobody's triaging totem-gstreamer
 bugs.

They could use basic triaging in the sense that someone should go
through them and see what applies to the 0.10 version.  I think that
you'd find most GStreamer bug triagers to mark them as obsolete if they
apply only to the 0.8 backend though, and I don't know if that's what
you want in this case.

I'm sure that for this kind of triaging you'll easily find some
volunteers in the GStreamr camp :)

What do you suggest ?

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
I go through all of this before you wake up
So I can feel happier to be safe up here with you
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
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

2006-01-16 Thread Thomas Vander Stichele
Hi,


 Well, if all other changes that have been done/will be done in 2.13 are
 only fixes that can go in 2.12, then I guess it's okay.
 
 Thomas also proposed to add a patch for GStreamer 0.10 support in CVS
 and a configure switch that would apply the patch.

My proposal was slightly different; I've added a command to turn the
tarball into a 0.10-based one.  After this command, you run autogen.sh,
and then make.

This is because the patch touches the build.

I put the tarball that is the result of this at
http://thomas.apestaart.org/download/tmp/gnome-media-2.13.0.tar.gz

I leave it to Ronald/release team to pick it up for tonight's release if
they're ok with it - Ronald seemed ok with it on IRC but I want to leave
it to someone else to make sure I don't step on any toes...

Night,
Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
If that's the way it is then that's the way it is
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: gnome-media branched

2006-01-14 Thread Thomas Vander Stichele
On Sat, 2006-01-14 at 12:09 +0100, Christian Rose wrote:
 On 1/10/06, Thomas Vander Stichele [EMAIL PROTECTED] wrote:
  gnome-media was branched for 2.12 (I think Ronald did this recently but
  it looks like no mail was sent out to announce it).
 
 Thanks for the notice.
 
 However, it seems there are serious problems with the gnome-2-12
 branch of gnome-media... All files appear not to have been tagged. On
 a checkout of gnome-media gnome-2-12 branch, several files are
 missing, including both source files and po files.
 Perhaps the tagging process was accidentally aborted somehow?

I have no idea what happened there.  I redid the branch command, did a
fresh checkout, and built it, and now things seem fine.

Can you confirm it works now ?

Thanks for spotting,
Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
And I know
they all look so good from a distance
but I tell you I'm the one
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


jhbuild and GStreamer

2006-01-14 Thread Thomas Vander Stichele
Hello everyone,

just a heads-up - jhbuild can now build both GStreamer 0.8 and 0.10
modules.  At this moment, both gnome-media and totem are built against
0.10 by default, so that we can get some feedback from the brave front
runners.

You can easily override this choice locally if you want:
- change autogen args for totem to --enable-gstreamer=0.8
- change branch for gnome-media to HEAD

If you want to make sure you can play patent-encumbered format files,
you can manually tell jhbuild to build the -ugly and -ffmpeg packages:
  jhbuild buildone gst-plugins-ugly-0.10
  jhbuild buildone gst-ffmpeg-0.10

gst-register does not exist anymore, the next time your applications
start up the new plugins will automatically be used.

It's not decided yet if gnome modules will depend on GStreamer 0.8 or
0.10 for Monday's release.  In practice, only 0.10 is actively
maintained, given that it's the latest stable version; however, some
work is still left to be added to the 0.10 stack, including porting of
some elements for proprietary formats, an implementation of sparse data
streams (for subtitles) and DVD support.

If you care about the choice, feel free to discuss it.  And please file
bugs on gnome-media and totem if you're testing it with the 0.10
back-end so we can work on them.

Thanks,
Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
Never knew there were only
ten million ways to love somebody
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


gnome-media branched

2006-01-10 Thread Thomas Vander Stichele
gnome-media was branched for 2.12 (I think Ronald did this recently but
it looks like no mail was sent out to announce it).

All bug fixes for 2.12 releases should go on the gnome-2-12 branch.
HEAD will now start merging patches for UI changes and GStreamer 0.10
integration.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
I may be love's bitch
But at least I'm man enough to admit it.
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


string freeze explanation on the wiki

2006-01-10 Thread Thomas Vander Stichele
Frustrated by my inability to easily find a string freeze explanation, I
created http://live.gnome.org/MaintainersCorner_2fStringFreeze based on
a mail from Christian Rose during the 2.9 cycle.  Feel free to further
change the page or suggest places in the wiki to link from to this page.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
I love the way you love
but I hate the way
I'm supposed to love you back
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: autotools gives autopain

2005-12-17 Thread Thomas Vander Stichele
Hi,

first of all, I love python.

 1. Scons is simply technically superior to GNU Autotools - with a big
margin.

Saying this does not make it automatically true.  Some further
explanation required.

 2. Scons is simple to learn, Autotools is not.

True.  However, autotools is already learned by enough people, scons is
not.

 3. KDE has already migrated to scons.

Not a useful argument.

 1. Autotools have worked so far, why switch?
 
- Because scons is easier and better.

It is easier, but not better.

  In the long run the benefits
  of a good build system outweighs the disadvantages of switching
  to it.

There are not much benefits to be had from switching - autotools is not
a bad build system.

 5. The migration to SCons will be really painful.
 
- Let's look at how KDE managed and learn from them. No change is
  without a price, but going from autotools to scons is worth it.

Saying it doesn't make it true.


FWIW - last time I checked, scons *still* did not support a basic
operation any maintainer needs called make distcheck.  This is a
minimum IMO - without it we shouldn't even discuss switching.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
That's funny ...
But it's not real !
I hope not, it's funnier when it is real
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Making GNOME crash

2005-11-11 Thread Thomas Vander Stichele
Hi,

   Oh, this is all fine for _GStreamer_, but bad for _GNOME_, because
 this sends away potencial GNOME contributors since it's simply too
 difficult to build it.  Sorry to be so blunt, but I think it was selfish
 of the GStreamer project to have -Werror in the makefiles.

Two notes:
- -Werror is only enabled for CVS; releases have it disabled by default.
-
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-cvs.html#werror
 also shows how easy it is to override the flags.

I also don't understand what you mean by selfish here.  What's selfish
about making sure we catch potential problems as soon as possible when
they're easy to fix ? Maybe we're selfish for licensing under the LGPL,
requiring people to send back their changes ?

This is free software - you are welcome to compile it with any flags you
like.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
Don't you see that my heart's on fire
wicked wings that you spread round me sometimes
All I know is we've got to aim higher
Babe I wish that we'd go for the great escape
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Gnome 2.14 Module Proposal: Deskbar Applet

2005-10-27 Thread Thomas Vander Stichele
On Wed, 2005-10-26 at 19:18 +0200, Benoît Dejean wrote:
 Le mercredi 26 octobre 2005 à 19:04 +0200, Thomas Vander Stichele a
 écrit :
  Hi,
 
  But are you sure that 10 python applets would each consume 22 MB ? How
  much of this 22 MB would be shared among python applets ?
 
 In my my first email, i reported that deskbar-applet takes 22MB RES :
 10MB are writable and can't be shared.

Ok, so the non-sharable part is about what you would accept as an
applet's consumption ?

Further, there are ways to make the applets share the python process
space, which would make them share a big chunk of the 10 MB
non-shareable space.

But I'm a little confused as to what alternative you are proposing
exactly - are you saying that all applets should be written in C until
the end of time ? I don't see any other way to avoid incurring some
memory loss for applets.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
My shite shits on your shite
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Gnome 2.14 Module Proposal: Deskbar Applet

2005-10-26 Thread Thomas Vander Stichele
On Wed, 2005-10-26 at 12:03 +0100, Mike Hearn wrote:
 On Tue, 25 Oct 2005 22:26:19 +0200, Raphael Slinckx wrote:
  I think the point is clear, python eats your memory, live with it.
 
 That's not a particularly great answer ...

Why not ? It is not different for any other language you could be using
except for C and C++.  What sort of answer would be better (and still
truthful) ?

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
The blood before me makes me open up my heart again
And I feel it coming over like a storm again
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Gnome 2.14 Module Proposal: Deskbar Applet

2005-10-26 Thread Thomas Vander Stichele
Hi,


   That excludes lots of users, me being the first.
 
 I'm sad to here it. Fully understood : you don't care about many of us
 (users. You don't mind ruining everyone else improvements. You're right,
 time is not to improvements, please everyone unsuscribe
 performance-list.

You are overreacting a little.  Raphael is making the point that this is
optional - if you don't add the appet to your panel, you won't incur the
memory loss.  So how would he be ruining other people's improvements ?

If I choose to run a program on my GNOME desktop today that does nothing
else than stat() and read() every file on my harddisk in an endless
loop, it does not ruin other people's improvements to GNOME.  I'll just
have a slow desktop, that's all.

  * Most users don't care about an applet taking a bit more memory than
  others, most will not even see it.
 
 This is wrong. Most users do care about performance. Many users switch
 from KDE because GNOME runs smoother on their computer. Many users
 switch to XFCE for the same reason.

He did not say users do not care about performance.  He is saying that
there are a lot of users that accept the tradeoff if they would use the
applet.  Obviously, you are not such a person, which is fine - you would
not be using the applet.

Settle down - you're being too antagonistic about this and it's making
the discussion go nowhere.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
My shite shits on your shite
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Gnome 2.14 Module Proposal: Deskbar Applet

2005-10-26 Thread Thomas Vander Stichele
Hi,


  Settle down - you're being too antagonistic about this and it's making
  the discussion go nowhere.
 
 then don't tell me the discussion about VM-based languages is over.

Ok, I won't.  Also note, I didn't.

  I
 started answering this thread with real statistics about memory usage. I
 then said i don't think deskbar-applet will one day take less than 20MB
 or resident memory.
 
 So my real point is : __I__ think 22MB of memory usage for a single
 applet (applet according Davyd's definition) is unaffortable. No applet
 should take more than 10MB (shared and non-shared). I'm running 10
 applets, how could i run 10 applets each taking 22MB ?

But are you sure that 10 python applets would each consume 22 MB ? How
much of this 22 MB would be shared among python applets ?

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
If you go
go for good
don't fucking joke
you know I would
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: xsltwin32config.h and jhbuild

2005-07-06 Thread Thomas Vander Stichele
  
  Why can't the necessary file be generated by Windows users?
 
   because configure doesn't run for people using standard Windows tools.

Daniel,

can you be a bit more specific ? What exactly does not allow people to
run configure under Windows ? Lots of projects build fine under windows
using the standard autotools set.


   people building from cvs like me just ignore that conflict, build and it 
 just works.

I would be surprised if that were true.  You have to *remove* the file.
If you leave it in a conflict it doesn't compile.  To be honest, it has
always bothered me before that this conflict is there, I just never took
the time to look into it like Federico did.  As James said, a conflict
in a cvs update should only happen because the user has local
modifications.

  jhbuild decides that the fact there is a conflict means a build
 must not be attempted, it's jhbuild decision to operate under that mode, and
 that's why it breaks in that case. It's not an human behaviour, it's jhbuild
 behaviour.

jhbuild cannot do anything else.  The conflict leaves markers in the
file that will cause it to not compile.  JHbuild can't make the
difference between a user change and a conflict because of this setup.
At this point the only thing that can solve it is manual intervention.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
I used to play with toy guns and knives with my daddy
He never taught me how to kill
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: roadmap status update/update request

2005-03-08 Thread Thomas Vander Stichele
Hi,

 I think that's a way better number of people 
 participating than MOST commercial companies would ever dream of to make a 
 market research on. They usually do their researches based on a sample of 
 2-3,000 people. Gnome would have 100 times that, and so I do take it that it 
 would be accurate enough.

I'm sorry, but I have to step in here and defend the basic principles of
statistics being violated here.  Sample size is not the only thing that
makes the outcome of a statistical polling accurate.  Your sample also
needs to be representative of whatever group you're sampling from.

Ie, if you ask 1 million rabbits if a Macintosh should have three mouse
buttons, you'd probably get a very reliable answer.  But it would be an
answer representative of what a rabbit is likely to think on the
subject.  It doesn't say *anything* about what a human would think.

As such, these companies doing their research on 2000-3000 people
probably have a much better selection process and take care to make sure
the sample chosen is representative of their target audience.  Getting
100 times that amount of people in your poll is likely to completely
mess up your poll instead of making it more statistically sound.

Defend mathematics ! Don't make statistics say something that you try to
make it say - do the research properly.


I now go back to taking my daily cough medicine.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
-*- thomas (dot) apestaart (dot) org -*-
- It's late - can we finish this some other time ?
- Oh - so you want to jump right to the kissing then. 
-*- thomas (at) apestaart (dot) org -*-
URGent, best radio on the net - 24/7 ! - http://urgent.fm/



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list