[haiku] Re: GSoC: Writing native interfaces for ported applications
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Fri, 02 Apr 2010 23:01:18 +0200
Hi,
> I kinda thought my proposal was late actually, but thanks for giving
> feedback so early, you wouldn't believe how long you can wait on some
> other
> projects, and for really disappointing answers.
thanks, keep it coming! :-D
> I was pretty sure that adding DVD read support to media player was a
> concrete idea, after seeing the reactions to it, and even though it looks
> pretty tricky, I think I'm up for the challenge.
You may have misunderstood me. The idea is totally concrete of course, as are
the rest of your bullet points. When you write "add streaming support to
MediaPlayer" it is totally clear what you mean by this. However the specific
implementation is of course not clear especially when you even mention more
than one possible way to do it in your proposal. That's what I mean by using
the remaining time to do more digging (as you appear to be doing), reading of
code, getting an overview, and then using what you learned combined with the
feedback you get to strengthen your proposal with more conrete action plans and
even a timeline.
> I'm surprised about the streaming though, I was pretty sure it was a
> utopian
> idea, but if the other ideas get scrapped I'll probably have time. It does
> rely on the services kit a bit though for my ideal use of services.
It would be perfectly fine IMHO if you only went for the DVD playback support.
If you manage to put this into the MediaKit, even if you implement it inside
MediaPlayer at first, it will have a much greater impact on the MediaKit API
when you transfer it eventually than the streaming addition would have.
> While discussing the tracker related ideas with Maxime, I did get the
> impression that it was a bit out of context, though I thought the capture
> ability media player offers could be used in the media kit. After hearing
> him describe how vectorial images were really embedded into the system, I
> was doubtful about being able to generate thumbnails for Tracker.
Actually the icon implementation is independent from Tracker. We have a nice
clean libicon in our codebase, which does the real handling of icon storage.
Applications however are just clients and use various APIs to retrive BBitmaps
or store opaque icon data. So it would be a matter of extending libicon for PNG
support (there is even a ticket I believe). No new APIs would need to be added.
B_CMAP8 bitmaps would be stored as they are now. B_RGBA32 bitmaps would be
stored as PNG (via the libicon backend that all public API uses) and retrieved
the same way. The distinction would be completely local to libicon.
> Any feedback on the tray icon/replicant idea? I was optimistic about it,
> but
> it seems like no-one else likes the idea...I might just "oh well..." that
> one.
The idea is sound. I think it's much more useful than a replicant on the
desktop. Since the implementation will not be challenging, I didn't comment or
request further details like with some other points in your proposal. So lack
of feedback doesn't mean lack of agreement at all. Most often quite the
contrary! :-)
> I'm reading through the code of media player right now to try and fix
> volume
> level storage for files, and though I was totally lost with the threading
> and program structure at the beginning, it's starting to sink in, along
> with
> a global idea.
That's the spirit! MediaPlayer is complex, and there is no overview type of
documentation. But I hope you find the code clean and once you follow some code
paths, I hope the flow of it becomes clear so that you feel confident to begin
changing it.
Best regards,
-Stephan
Other related posts:
