Visualization options are worse than totem-xine

Thanks for your bug. Please use bug to describe one issue you have, not to list things that are differents, that's not useful. I'm rejecting that bug since there is no real description of an issue but rather some complain about lack of feature. Feel free to open differents bugs with clear description of what is "nearly as good" or on how the zoom level doesn't work (do you use xvimage videosink, etc)

I'm supposed to describe specifically how one version of goom is not nearly as good as another? Good luck with that! (If you had tried to repro the bug, I think you'd have been able to see what I describe.)

The zoom I refer to is when you press 0, 1, 2 in totem and it resizes the window and makes the picture bigger. I don't know what that xvimage or videosink.

These comments all relates to the visualizations in totem-gstreamer seem to be different and inferior to totem-xine. In that sense I think it makes sense to keep it as one bug.

change reject status because I believe this is one bug related to totem visualizations.

I understand what you describe, but that's rather a feature request to code new visualization modes for gstreamer. That's not something we are likely to code on specifically for Ubuntu and would be better placer as a launchpad specification or to a discussion upstream. I'm rejecting the request since we are not real point to keep such feature requests as bugs, better to open a specification about making better vizualisations for gstreamer by example

It isn't a matter of 'coding new visualizations'--its a matter of making totem-gstreamer have the same ones as totem-xine. They are mostly the same codebase, why can't they have the same visualizations?

The totem-gstreamer visualizations are brokenand I'll bet the fix isn't huge.

I've filed bugs upstream and not rejected them here--they just wait.
I don't think its good to reject bugs without putting them into specs first.
Anyway, I do see other 'wishlist' bugs, why does mine have to be rejected?

Finally, I do believe this is closer to a bug than a feature. But if you call it a feature you can reject it and forget about it and that isn't really good.

I'm unmarking it as a wishlist because it is much closer to a bug than a feature. The UI and codebase for totem is mostly the same, yet the visualization options are different.

I'll bet if sabdfl saw this bug, he'd think we need to fix it. Does Ubuntu want people to use totem-gstreamer or not? If it has broken visualizations, people won't use it.

BTW, if you had more devs, you could fix this bug, which in a sense makes this bug a wishlist item for Ubuntu today.

However, wishlist should represent pie in the sky stuff, like supporting multiple batteries in the power management UI, or coding for features that do not exist today.

Some points to reply to your flood of comment:
- usually playing with the bug settings against the maintainers willing will not force them to accept your opinion but rather make them ignore you or conflict on that rather discussing on the bug, better to argue to get them changing those than trying to force them by yourself
- the codebase is not the same, the visualizations come from libxine and gstreamer, goom for totem-gstreamer is by example:
gstreamer0.10-plugins-good: /usr/lib/gstreamer-0.10/libgstgoom.so
- upstream keep feature request because they are the guys who write the code and where a new feature is likely to be coded, we do packaging, stabilization, integration, bug fixing, etc so we have no interest to keep feature requests we will no work on
- usually we forward feature request upstream but that one is a collection of different issue, with no precise points and with most assigned to wrong place
- if you want feel free to show that bug to the sabdfl, look at the launchpad list, there is lot of bugs to fix but few people working on them so it'll take time and we have to prioritize the work, he probably knows about that
- I don't think people will stop using the video player because it has not good visualization, they watch videos with it

Now you want try something? Open the same bug you opened here on bugzilla.gnome.org and wait if upstream has a better reply for it, upstream is the right place to get that worked anyway

I wrote software for over a decade and worked with many testers and I know
that rejecting a bug against the person who went to the trouble of isolating
and filing the bug isn't good either. When a bug gets rejected and forgotten
about, the knowledge gets lost.

Yes, I definitely agree you guys have lots of bugs to fix, but just because
you are buried in bugs doesn't mean you should start rejecting them. It
might make you feel better, but it doesn't make the codebase any better.

You tell me to file a bug upstream, but then shouldn't this bug stay around?
Are you saying that bugs with upstream links should be rejected?

I watch videos but also listen to a lot of music--Totem isn't just about
video otherwise it wouldn't have visualizations.

I would open a bug upstream if I knew for sure it happened there. Who added
goom to totem--Debian or Gnome?

I don't know why you keep saying this bug is a collection of different
issues. Its all related to visualizations and totem-gstreamer. I could see
breaking it up into 2 bugs:
goom in totem-gstreamer doesn't support high resolution
visualization choices in totem-gstreamer aren't the same as totem-xine.

Would it make you feel better if I filed it as 2 bugs? Or would you just
reject those as well?

the point about sabdfl is that I'll bet he wouldn't consider this a 'pie in
the sky' wishlist feature.

On 5/10/06, Sebastien Bacher <email address hidden> wrote:
>
> Some points to reply to your flood of comment:
> - usually playing with the bug settings against the maintainers willing
> will not force them to accept your opinion but rather make them ignore you
> or conflict on that rather discussing on the bug, better to argue to get
> them changing those than trying to force them by yourself
> - the codebase is not the same, the visualizations come from libxine and
> gstreamer, goom for totem-gstreamer is by example:
> gstreamer0.10-plugins-good: /usr/lib/gstreamer-0.10/libgstgoom.so
> - upstream keep feature request because they are the guys who write the
> code and where a new feature is likely to be coded, we do packaging,
> stabilization, integration, bug fixing, etc so we have no interest to keep
> feature requests we will no work on
> - usually we forward feature request upstream but that one is a collection
> of different issue, with no precise points and with most assigned to wrong
> place
> - if you want feel free to show that bug to the sabdfl, look at the
> launchpad list, there is lot of bugs to fix but few people working on them
> so it'll take time and we have to prioritize the work, he probably knows
> about that
> - I don't think people will stop using the video player because it has not
> good visualization, they watch videos with it
>
> Now you want try something? Open the same bug you opened here on
> bugzilla.gnome.org and wait if upstream has a better reply for it,
> upstream is the right place to get that worked anyway
>
> ** Changed in: totem (Ubuntu)
> Severity: Normal => Wishlist
> Priority: None => Low
> Status: Unconfirmed => Rejected
>
> --
> Visualization options are worse than totem-xine
> https://launchpad.net/bugs/43319
>

Le mercredi 10 mai 2006 à 16:41 -0700, Keith Curtis a écrit :
> I wrote software for over a decade and worked with many testers and I
> know that rejecting a bug against the person who went to the trouble
> of isolating and filing the bug isn't good either. When a bug gets
> rejected and forgotten about, the knowledge gets lost.

That's why I advise you to file it upstream which is the right place

> Yes, I definitely agree you guys have lots of bugs to fix, but just
> because you are buried in bugs doesn't mean you should start rejecting
> them. It might make you feel better, but it doesn't make the codebase
> any better.

As said we have to that much interest to keep coding tasks, we mainly do
integration work and bug fixing, new feature are usually done upstream

> You tell me to file a bug upstream, but then shouldn't this bug stay
> around? Are you saying that bugs with upstream links should be
> rejected?

Not, but they have basically the same effect "it's not for Ubuntu", we
pass the bug at the right place and let them decide what they want to do
with it.
The issue with your bug is that it mixes issue for different packages,
it's not as easy as you think and I'm reluctant to forward a bug that
looks like a "rant" about totem-gstreamer because that's not the best
way to deal with upstream

> I would open a bug upstream if I knew for sure it happened there. Who
> added goom to totem--Debian or Gnome?

Nobody, goom is an effect shipped by xine-lib as said previously. It
happens than gst-plugins-good0.10 also has a goom implementation

> I don't know why you keep saying this bug is a collection of different
> issues.

* "I only get one, rather than the 4 which ships with totem-xine."

That's one wishlist "please code new visual effect for gstreamer"

* "The zoom 1:2, 1:1, 2:1 doesn't seem to do anything."

That's a "zoom is not working" bug. I'm not sure if the zoom is supposed
to apply to visual effects though, in which case it should be
unsensitive which is still a small bug

* "The version of goom isn't nearly as good as the totem-xine one."

That is a maybe true but non useful statement. How is it no good. Is
that a speed issue? A graphical issue? What is not right about it? What
would you want to get changed? Better speed? Extra details? Other
implementation detail?

> Would it make you feel better if I filed it as 2 bugs? Or would you
> just reject those as well?

A wishlist for coding new effects would be accepted and forwarded
upstream
A bug about the zoom issue would be investigateed
An another "goom isn't nearly as good" with no description of what you
expect would be rejected, if you describe it the way I explained before
we will forward it upstream

> the point about sabdfl is that I'll bet he wouldn't consider this a
> 'pie in the sky' wishlist feature.

Maybe, maybe not ...