transKode

Tue Mar 4 07:59:04 UTC 2008

I apologize in advance if this got posted at the top level again (the Yahoo
web mail client doesn't play well with the list...)

Now to the point.... It's true that binary scripts can't be reasonable
distributed as I done until now with transKode, which is why, as
I've said, I won't be doing it anymore. But that's also why I suggested
distributingit directly with Amarok. All the problems attributed here
tobinary scripts automatically go away in that scenario.
Also, transKode depends solely onTagLib and Qt/KDELibs, so no
additional dependencies would be required (andthere wouldn't be a
need to compile it as a static binary either as someone suggested). I
don't think there's a problem with binary scripts per se, just with their
distribution. Regardless,there are at least 3 possible choices in dealing
with this issue:
1) Include transKode script more or less as it is with Amarok (once
ported to Qt/KDE 4)
2) Port transKode to Ruby or Python (and maybe include it with
Amarok)
3) Make transcoding part of Amarok itself.
IfI'm not alone in thinking Amarok should ship a default transcoding
script, then the first option has the obvious advantage of being the one
that requires less work. I think the non trivial effort of porting it to Ruby
or Python only begins to make sense if the intention continues to be not
to provide a default script; in which case I'd like to hear the reason forit.
I seriously doubt I'll be porting transKode to Ruby or Python myself
(though if anyone else want to do it, then fine by me). The language
port itself is annoying enough, but it's not the only problem: 1) It will add
moredependencies: QtRuby and Korundum for Ruby or PyQt and
PyKDE for Python. It may be perfectly acceptable for a transcoding
script to be "just" a Qt app, but  transKode is not just a script and
looking at the "bigger picture" it is and will remain a KDE app.
Some of the GUI aspects can be modified to be Qt only (at least for
the script), but some parts in the core will still depend on KDELibs
(for example, the current worker threads and jobs will be ported to
Threadweaver) 2) While I prefer Ruby over Python, threads support is
lame in the first, so Python might actually be the only reasonable language
choice. That's not an terrible problem as some people surely prefer
Python over Ruby... just not me. 3) Porting will most likely carry other
problems aswell. For instance, most encoders dialogs are currently Qt
Designer dialogs (XML files), code generated at compile time and 
subclassed, I don't think QtRuby nor PyQt can handle this. Also, I'm
not sure how internationalization will work in this scheme (though this is
probably a non-issue).
Now, there's still the third option... both Mark and Ian have expressed
their doubts aboutwhether the transcoding aspect should be handled by
a script at all.Given that, don't you guys think it's reasonable to have
some sort of discussion on that topic? Unlike with the 2nd choice I listed,
I might actually be willing to cooperate with that.

Sergio.

----- Mensaje original ----
De: Miguel Angel Alvarez <maacruz at gmail.com>
Para: Amarok Mailing List <amarok at kde.org>
Enviado: sábado 1 de marzo de 2008, 20:44:30
Asunto: Re: transKode

El Sábado 01 Marzo 2008, Colin Guthrie escribió:
> Miguel Angel Alvarez wrote:
> > El Miércoles 27 Febrero 2008, Mark Kretschmann escribió:
> >> On 2/27/08, Ian Monroe <ian at monroe.nu> wrote:
> >>> On Tue, Feb 26, 2008 at 2:57 PM, Sergio Pistone
> >>>
> >>>  <sergio_pistone at yahoo.com.ar> wrote:
> >>>  > Hi, my name is Sergio Pistone, and I'm the author of transKode, one
> >>>  > of the scripts that can be used to transcode file to audio devices
> >>>  > (at least in the 1.4.x branch, I don't know if things will work the
> >>>  > same way for the 2.x release).
> >>>
> >>>  Really it shouldn't be your job to package it. I agree with you that
> >>>  you shouldn't make binaries of it. Thats the distros job. We could
> >>>  help you get in contact with them.
> >>
> >> It being a binary is really the main problem. Back in the day when I
> >
> > No, it isn't. It simply should be a static binary, and that's all.
>
> For what arch? i586, i686, x86_64, MMX extensions, CMOV support, 
For those just one binary fits all
> PPC, 
> Sparc, ARM, Windows EXE, OSX binary etc?
For those one binary for arch, evidently
>
> Binaries are evil when thinking about this kind of stuff. It's all well
> and good when you live in a windows 32 bit bubble but in the real world
> where people often run linux (and thus Amarok) on their toasters and
> dead badgers then binaries can and, as is clearly evident, do cause
> headaches.
I'm not saying that binaries do not cause headaches, but they are not so evil. 
Even script languages can cause quite a headache (just think about language 
versions, modules, etc). Even using just bare python, same release, I can't 
run the same script on linux and win.
But.... why I'm defending binaries? Just because on some ocassions they are 
the only option to do something in a reasonable time frame.

>
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok

-- 
Don't see the world through a window, be open{source}minded, and be free :-)
_______________________________________________
Amarok mailing list
Amarok at kde.org
https://mail.kde.org/mailman/listinfo/amarok

      Tarjeta de crédito Yahoo! de Banco Supervielle.
Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20080303/73d0b47f/attachment.html>