VDR developer version 1.5.x

free-x · 7 Янв 2007

Цитата

VDR developer version 1.5.0 is now available at

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

A 'diff' against the latest stable version is available at

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

WARNING:
========

This is a *developer* version. Even though *I* use it in my productive
environment, I strongly recommend that you only use it under controlled
conditions and for testing and debugging.

This version focuses mainly on improvements in CAM handling.
The highlights are:

- Improved CAM menu and reset handling.
- Automatic selection of suitable CAM in a system with several CAMs
that claim to decrypt a given channel.
- Decrypting of several channels on the same transponder (if the
CAM is able to do this).

The changes since version 1.4.5:

- The CAM handling has been refactored. Instead of a cCiHandler per device there
is now an abstract cCiAdapter and a cCamSlot. This allows each slot to be
accessed individually.
- The general 15 seconds workaround time before opening the CAM menu has been
removed. If the CAM menu doesn't open within a timeout, the enter menu command
is now sent again.
- If a CAM is reset or pulled and reinserted, it now automatically starts
decrypting the current channel again.
- The Setup/CAM menu now dynamically refreshes its items and displays whether
a CAM is present or ready. The 'Reset' function no longer leaves the menu.
- The CAM menu will now be openend when pressing the Ok key on a slot entry.
- The CAM menu now stays within the current menu context and doesn't close and
reopen the menu every time an option is selected.
- When an encrypted channel is switched to for the first time, VDR now checks
explicitly whether a CAM can actually decrypt that channel. If there is more
than one CAM in the system that claims to be able to decrypt the channel,
they are all tried in turn.
To make this possible, an encrypted channel needs to be received in Transfer
Mode when it is switched to for the first time, so that VDR can determine
whether the TS packets are actually decrypted. Once a channel is known to
be decrypted by a particular CAM, the next time it is switched to it will
be shown in normal live viewing mode.
- A cDevice now automatically detaches all cReceiver objects that receive PIDs
that can't be decrypted with the current CAM. A plugin that attaches a cReceiver
to a device should therefore watch the receiver's IsAttached() function to
see if it is still attached to the device.
- The cReceiver constructor no longer takes an 'int Ca' as its first parameter,
but rather a 'tChannelID ChannelID'. This is necessary for the device to be
able to determine which CAM a particular channel can be decrypted with. If the
channel is known to be unencrypted, or a plugin doesn't want to provide the
channel id for other reasons, an invalid tChannelID() can be given.
- The cThread::Start() function now waits until a previous incarnation of this
thread has actually stopped. Before this it could happen that a thread's
Cancel(-1) function was called and immediately after that it was started again,
but the Start() function still found it to be 'active'.
- The parameter NeedsDetachReceivers in cDevice::GetDevice(const cChannel *Channel, ...)
has been removed. A call to this function will automatically detach all receivers
from the device if it returns a non-NULL pointer.
- The cTimeMs class now accepts an initial timeout value in its constructor.
- A CAM is now explicitly instructed to stop decrypting when switching away from
an encrypted channel.
- If the CAM in use can decrypt several channels at the same time, VDR can
now make use if this capability. Whether or not a CAM can decrypt more
than one channel is determined by sending it an initial empty QUERY command
and testing whether it replies to it.
- Ca values in the range 0...F in channels.conf can still be used to assign a channel
to a particular device, but this will no longer work with encrypted channels because
without valid CA ids VDR can't decide which CAM slot to use. However, since VDR now
automatically determines which CAM can decrypt which channel, setting fixed
channel/device relations should no longer be necessary.

KNOWN BUG - PLEASE HELP DEBUGGING:

Start VDR with only one FF DVB card and an attached CI with a CAM.
Switch to an encrypted channel for the first time, the channel is shown
in Transfer Mode. Wait for at least 10 seconds, so that VDR will mark
the CAM as "able to decrypt this channel".
Now switch to the same channel again (by selecting it from the Channels
menu or typing in its number), and the screen goes black. VDR is now
receiving the channel in normal live mode (no Transfer Mode).
Apparently there is a problem with switching to live mode after using
Transfer Mode.
The problem goes away if you switch to a channel on a different transponder
and then back to the original one. Now it is shown even in normal live mode.

I did a lot of debugging to find out why this goes wrong, but was unable
to fix it. Maybe somebody out there can find out why this doesn't work.

Have fun!

Klaus

Показать весь код

Делаем ставки когда выйдет 1.6.0

free-x · 7 Янв 2007

КЛС проговорился о том что будет в 1.5 версии разрабатываться

Цитата

Devices with multiple frontends
New shutdown code
Framebuffer sharing
UTF-8 for texts
I18N with 'gettext'
TrueType fonts
Subtitles
Multiple SVDRP connections

Показать весь код

По моему не очень много чего нового. Кое что у нас уже есть благодаря Trantor

warp · 15 Янв 2007

Попробовал. Софткам не садится, UTF8 не работает. Подождём финального релиза.

free-x · 15 Янв 2007

пока месть дергаться нечего..... пусть разбираются

Bikalexander · 15 Янв 2007

Первые патчи для обиходных плагинов .....

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

free-x · 25 Фев 2007

Цитата

VDR developer version 1.5.1 is now available at

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

A 'diff' against the previous developer version is available at

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

WARNING:
========

This is a *developer* version. Even though *I* use it in my productive
environment, I strongly recommend that you only use it under controlled
conditions and for testing and debugging.

The changes since version 1.5.0:

- Added cDevice::HasCi() so that devices with Common Interface can be avoided
when tuning to an FTA channel, thus preserving the CAM resources even on budget
DVB cards (suggested by Petri Helin).
- Fixed i18n characters for the Hungarian texts (thanks to Thomas Gьnther).
- Now using cPipe instead of popen() in cCommand::Execute() to avoid problems
with open file handles when starting background commands (thanks to Reinhard
Nissl).
- Removed 'assert(0)' from cDvbSpuDecoder::setTime() (thanks to Marco SchlьЯler).
- Fixed a possible crash when loading an invalid XPM file (thanks to Martin Wache).
- Updated satellite names in 'sources.conf' (thanks to Thilo Wunderlich).
- Adapted 'libsi' to DVB-S2 (thanks to Marco SchlьЯler).
- Fixed handling error status in cDvbTuner::GetFrontendStatus() (thanks to
Reinhard Nissl).
- Shutdown handling has been rewritten (thanks to Udo Richter).
- Plugins can now implement the new function WakeupTime() to request VDR to wake
up at a particular time (thanks to Udo Richter).
- The HUP signal now forces a restart of VDR (thanks to Udo Richter).
- cThread::EmergencyExit() has been replaced by ShutdownHandler.RequestEmergencyExit().
- Several references to "button" in a remote control context have been changed
to "key" (based on a report from Marko Mдkelд regarding the "Menu button closes"
text). The "MenuButtonCloses" parameter in 'setup.conf' has therefore been
renamed to "MenuKeyCloses", accordingly. This will result in an "unknown config
parameter: MenuButtonCloses" error message in the log file, so you may want to
remove that entry from your 'setup.conf' file.
- Simplified the error handling in cDvbTuner::GetFrontendStatus() (based on a
discussion with Reinhard Nissl).
- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- Increased the maximum number of DVB devices to 8 (thanks to Rolf Ahrenberg).
- The new Setup parameter "Channel entry timeout" can be used to customize the time
since the last keypress until a numerically entered channel number is considered
complete, and the channel is switched (suggested by Helmut Auer). Setting this
parameter to 0 turns off the automatic channel switching, and the user will
have to confirm the entry by pressing the "Ok" key.

KNOWN BUG - PLEASE HELP DEBUGGING:

Start VDR with only one FF DVB card and an attached CI with a CAM.
Switch to an encrypted channel for the first time, the channel is shown
in Transfer Mode. Wait for at least 10 seconds, so that VDR will mark
the CAM as "able to decrypt this channel".
Now switch to the same channel again (by selecting it from the Channels
menu or typing in its number), and the screen goes black. VDR is now
receiving the channel in normal live mode (no Transfer Mode).
Apparently there is a problem with switching to live mode after using
Transfer Mode.
The problem goes away if you switch to a channel on a different transponder
and then back to the original one. Now it is shown even in normal live mode.

I did a lot of debugging to find out why this goes wrong, but was unable
to fix it. Maybe somebody out there can find out why this doesn't work.

Have fun!

Klaus

Показать весь код

Courage · 25 Фев 2007

Цитата

Adapted 'libsi' to DVB-S2 (thanks to Marco SchlьЯler).

первые телодвижения похоже в сторону dvb-s2 - а что за библиотека?
за что отвечает?

free-x · 25 Фев 2007

смотри в корневой директории vdr есть libsi/

Courage · 25 Фев 2007

без пол-банки не разберешься - но по скупым комментариям в headers вроде
все файлы в этой директории libsi для работы с спутниковыми таблицами
nat nit si и т.д. и отдельный модуль съема времени ......чую надо собирать
что нить посвежее чем старый добрый 1.4.0

Bikalexander · 22 Апр 2007

Цитата

VDR developer version 1.5.2 is now available at

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

A 'diff' against the previous developer version is available at

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

I haven't had time to work on VDR in the past few weeks, so several
bugfixes etc. that have been posted on the mailing list are still in
my inbox and I have yet to look into them. I just wanted to get this
version out now, because it implements a very first step into using
UTF-8 character encoding. If you're using a language that has many
non-7bit-ASCII characters, you may not want to use this version.
However, if your language uses only a few such characters (like German),
running this version on a UTF-8 system should at least get the file
names of recordings right - even though the umlauts will not be
displayed correctly on the OSD).

WARNING:
========

This is a *developer* version. Even though *I* use it in my productive
environment, I strongly recommend that you only use it under controlled
conditions and for testing and debugging.

The changes since version 1.5.1:

- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- Fixed handling user activity for shutdown, which I had messed when adopting Udo's
original patch (thanks to Udo Richter).
- Added Turkish language texts (thanks to Oktay Yolgeзen).
- Added missing rules for generating iso8859-13 font to Makefile.
- 'libsi' now converts the incoming strings into the system's character set
according to the DVB standard. The system's character set is determined from
the LANG environment variable. If no recognizable setting can be found, no
conversion will take place. Note that currently only the strings received from the
SI data stream are converted, there have not been any changes regarding displaying
UTF-8 characters on the OSD, yet - this will follow in one of the next steps.
With this conversion, it should now be safe to run VDR on a UTF-8 file system,
because all incoming characters are converted to UTF-8. This will most likely
result in wrong characters being displayed on the OSD (because there UTF-8 is
not known, yet), but the file names should be ok (haven't tested this myself,
though, because I don't do UTF-8 - so please be very careful when testing!).
There's one piece of bad news here: the German pay-tv broadcaster Premiere
apparently encodes all EPG strings as ISO8859-1, but fails to correctly mark
these strings as such. Therefore 'libsi' (following the DVB standard) considers
the strings to be encoded in the default ISO6937 and converts them to whatever
the system's character set is. This, of course, results in wrong umlauts.
On its old transponder, the ProSieben/SAT.1 channels also had their EPG data
wrongly encoded, but apparently on the new transponder they started broadcasting
on this month, they got it right.

Have fun!

Klaus

Показать весь код

Bikalexander · 11 Май 2007

Может кому интерестно, сегодняшняя переписка автора VDR о теме UTF-8 ....я правда мало чего понял, разве что автор не очень то и хочет поддерживать UTF-8..

Цитата

On 05/11/2007 09:25 AM, Ludwig Nussel wrote:
> Klaus Schmidinger wrote:
>> On 05/10/07 20:04, Udo Richter wrote:
>>> ...
>>> VDR development would speed up, if Klaus would delegate more work to
>>> other talented coders, and doing more review instead of coding most of
>>> it himself.
>> Well, right now I'm dealing with the UTF-8 stuff, which is something
>> I myself don't need at all. But unfortunately the patch(es) for this
>> can't just be applied as it, because from what I've seen so far there
>> it is assumed that the whole program is totally going UTF-8 - which it
>> is *not*. I still want to be able to run it on a pure and clean iso8859-1
>> system. So I have to painstakingly go through the whole thing and take care
>> that it only does UTF-8 if so requested - and that's a lot more work than just
>> applying a patch...
>
> What's wrong with vdr using UTF-8 internally if it makes the code simpler?
> Offhand I could only imagine two places where using a different external
> encoding would be required and that's file names and tty i/o. Stuff like
> epg.data and svdrp should better use UTF-8 as you don't need to add extra meta
> data options to specify the encoding.

It's very simple: I don't like it!
The two languages I can handle can be perfectly well represented with iso8859-1,
so I just don't want to have to go through all the hassle with UTF-8.
To me, a character is a character is a byte is a byte. Period.

Now, I do see that there are people out there who can't represent their
language with single byte character sets, or want to be able to handle
more languages than a single character set can cope with, so I am going
to make VDR able to handle UTF-8. But only in a way that allows (at least)
me to completely turn this stuff off. Whenever I install a new version
of SUSE Linux, the first this I always do is turn off UTF-8. I just don't
want it and don't need it.

Klaus

------------------------------

Message: 2
Date: Fri, 11 May 2007 10:50:01 +0200
From: Lucian Muresan <lucianm@users.sourceforge.net>
Subject: [vdr] Re: A few observations on the vdr project
To: VDR Mailing List <vdr@linuxtv.org>
Message-ID: <46442E39.9010001@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1

Klaus Schmidinger wrote:
> On 05/11/2007 09:25 AM, Ludwig Nussel wrote:
>> Klaus Schmidinger wrote:
>>> On 05/10/07 20:04, Udo Richter wrote:
>>>> ...
>>>> VDR development would speed up, if Klaus would delegate more work to
>>>> other talented coders, and doing more review instead of coding most of
>>>> it himself.
>>> Well, right now I'm dealing with the UTF-8 stuff, which is something
>>> I myself don't need at all. But unfortunately the patch(es) for this
>>> can't just be applied as it, because from what I've seen so far there
>>> it is assumed that the whole program is totally going UTF-8 - which it
>>> is *not*. I still want to be able to run it on a pure and clean iso8859-1
>>> system. So I have to painstakingly go through the whole thing and take care
>>> that it only does UTF-8 if so requested - and that's a lot more work than just
>>> applying a patch...
>> What's wrong with vdr using UTF-8 internally if it makes the code simpler?
>> Offhand I could only imagine two places where using a different external
>> encoding would be required and that's file names and tty i/o. Stuff like
>> epg.data and svdrp should better use UTF-8 as you don't need to add extra meta
>> data options to specify the encoding.
>
> It's very simple: I don't like it!
> The two languages I can handle can be perfectly well represented with iso8859-1,
> so I just don't want to have to go through all the hassle with UTF-8.
> To me, a character is a character is a byte is a byte. Period.
>
> Now, I do see that there are people out there who can't represent their
> language with single byte character sets, or want to be able to handle
> more languages than a single character set can cope with, so I am going
> to make VDR able to handle UTF-8. But only in a way that allows (at least)
> me to completely turn this stuff off. Whenever I install a new version

Isn't that constraint going to add too much unnecessary overhead to the
code? I guess you'd be then forced to take care of handling both
requirements forever, with every future version. Is that really what you
want, only to satisfy the "I don't like it" reason? I mean, you're
already doing a compromise at least, and a lot of us salute this, I'm
only wondering if it wouldn't actually make your life easier if
supporting just one of 2 things you want to support anyway, the
complicated one, UTF-8, and the hassle-free one, non-utf-8. Since you're
willing to support UTF-8, the other one is in my opinion, just extra
work from now on, slowing down development (God beware, I'm not tryin'
to push you)...

> of SUSE Linux, the first this I always do is turn off UTF-8. I just don't
> want it and don't need it.
>
> Klaus

------------------------------

Message: 3
Date: Fri, 11 May 2007 11:46:04 +0200
From: Ludwig Nussel <ludwig.nussel@suse.de>
Subject: Re: [vdr] A few observations on the vdr project
To: vdr@linuxtv.org
Message-ID: <200705111146.05154.ludwig.nussel@suse.de>
Content-Type: text/plain; charset="iso-8859-1"

Klaus Schmidinger wrote:
> On 05/11/2007 09:25 AM, Ludwig Nussel wrote:
> > What's wrong with vdr using UTF-8 internally if it makes the code simpler?
> > Offhand I could only imagine two places where using a different external
> > encoding would be required and that's file names and tty i/o. Stuff like
> > epg.data and svdrp should better use UTF-8 as you don't need to add extra meta
> > data options to specify the encoding.
>
> It's very simple: I don't like it!
> The two languages I can handle can be perfectly well represented with iso8859-1,
> so I just don't want to have to go through all the hassle with UTF-8.
> To me, a character is a character is a byte is a byte. Period.

Come on, take some "Scheissegalpillen" and stop beeing stubborn
I aggree that UTF-8 isn't exactly delightful but from a user's point
of view the hassle with UTF-8 is less than the hassle having to deal
with multiple encodings. I mean even when ignoring languages other
than German you have trouble with the stupid euro sign when using
iso8859-*. Look at the bright side of UTF-8, at most places you
don't really have to care about the actual characters so you don't
need special treatment. After all it could be worse. If the new
standard would be a fixed width multibyte encoding with embedded
null bytes you'd have to really rewrite all your code.

cu
Ludwig

--
(o_ Ludwig Nussel
//\ SUSE Labs
V_/_ Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

------------------------------

Message: 4
Date: Fri, 11 May 2007 11:48:30 +0200
From: "Dieter Fauth" <dmfhhp@web.de>
Subject: Re: [vdr] A few observations on the vdr project
To: "VDR Mailing List" <vdr@linuxtv.org>
Message-ID: <op.tr5pi4g968z9gh@mail.web.de>
Content-Type: text/plain; format=flowed; delsp=yes;
charset=iso-8859-15

Hi Klaus,
in our devices (barcode reader) we use 16 bit characters and it works out
nice and easy and very similar to the old bytes.
It was not easy to convince my collegues (in the USA), but I managed to do
it.

IMHO this is much simpler than the UTF8, all the index into a string still
works.
I added overloads of the lib functions which are 16 bits wide
Example: wchar_t *strcpy(wchar_t *pOut, wchar_t *pIn);
So the code even looks like in the old days.
If you like I can mail you some files.

This approach seams to be not used in the Linux world, I do not understand
why. UTF8 is a pain!
The argument about the bigger buffers do not count in todays devices and
is not that much.
You only have to be carefull to treat characters as such and binary bytes
as such (still a byte).
Many programmers mix that up.

--
Many regards, Dieter Fauth

------------------------------

Показать весь код

Bikalexander · 11 Май 2007

Ща прочитал дальнейшие посты в переписке и нифига не пойму чего хочет замутить сам автор и от чего и почему его трантор отговаривает?

free-x · 11 Май 2007

Сказав А, т.е. приняв решение об УТФ, надо сказать и Б, переход на другой тип для символов, т.е. wchar_t
Что означает переписывание очень многих частей VDR. Чего конечно же KLS не хочет ....
Т.е. или сделать все с самого начала правильно либо снова подставлять костыли

free-x · 27 Май 2007

Цитата

Subject: [vdr] Dropping pixel font in VDR 1.5?
Date: Sun, 27 May 2007 18:49:44 +0200

I'm currently implementing support for Freetype fonts in VDR 1.5
(based on Alexander Riedel's patch) and would like to completely
drop all the pixel font stuff.

Just to make sure there won't be somebody who absolutely needs
the pixel fonts, please let me know if this is ok. Since probably
most of you will be running VDR with UTF-8 anyway (once it is
supported, which will be very soon), my guess would be that the
pixel fonts are really obsolete.

Klaus

Показать весь код

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

schpuntik · 27 Май 2007

Хорошие новости. Радует что Клаус обратил внимание на решение с нашего дистра. Значит всё идёт по плану! Значит все плагины будут перерабатываться на UTF-8 поддержку!

Multi VDR · 27 Май 2007

Наконецто дождались.

trantor · 27 Май 2007

глубоко надеюсь что "completely
drop all the pixel font stuff" не свян с тем что я так и не доделал возможность паралелльной работы ТТФ и Фиксед фонтов.

Цитата

Со слов пользователя free-x

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

free-x · 29 Май 2007

Цитата

Anti-aliased freetype fonts really do look good

Klaua

так писяет что даже имя свое забыл

free-x · 10 Июн 2007

ну вот и кота из мешка вытащили

Цитата

VDR developer version 1.5.3 is now available at

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

A 'diff' against the previous developer version is available at

Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

This version finally brings UTF-8 capability to VDR!
There are still a few minor details to iron out, but all in all
it already works pretty good.

Note that if you run VDR on a UTF-8 system, it will write all its
text files using UTF-8. Existing text files written in ISO will
not be automatically converted to UTF-8. You will need to do this
yourself if necessary. Channel and EPG data will be automatically
changed to UTF-8 as new data comes in.

If you run VDR on a system with ISO character set, files will still
be stored in ISO just as before.

Several bugfixes etc. that have been posted on the mailing list lately
are still in my inbox and I have yet to look into them.

WARNING:
========

This is a *developer* version. Even though *I* use it in my productive
environment, I strongly recommend that you only use it under controlled
conditions and for testing and debugging.

The changes since version 1.5.2:

- Fixed some spelling errors in 'newplugin' (thanks to Ville Skyttд).
- Fixed a busy loop in fast forward if the next video data file is missing
(thanks to Reinhard Nissl).
- Fixed handling frequencies in NitFilter::Process() (thanks to Anssi Hannula).
- Fixed a race condition with signal handlers at program exit (thanks to Udo
Richter).
- Non-primary devices in Transfer mode are now also used for recording (thanks
to Anssi Hannula).
- Fixed handling ChannelUp/Down keys if there is currently a replay running
(thanks to Marco SchlьЯler).
- The new SVDRP command REMO can be used to turn VDR's remote control off and
on in case other programs need to be controlled (based on patches from Krzysztof
Parma and Helmut Auer).
- Increased the maximum number of CA system ids to cope with the AlphaCrypt
CAM's version 3.11 firmware.
- Fixed getting the code setting from the locale (thanks to Matthias Schwarzott).
- Implemented support for Freetype fonts (based on a patch from Alexander Riedel).
The font names and sizes can be adjusted in the "Setup/OSD" menu.
Note that VDR now requires freetype fonts to be installed in
/usr/share/fonts/truetype.
- If the OSD device in use has at least 8bpp bitmap depth and this is also
used by the current skin, Freetype fonts are displayed "anti-aliased".
The new setup parameter "OSD/Anti-alias" can be used to turn this off.
- The new function cOsd::SetAntiAliasGranularity() can be used to help the OSD
in managing the available color palette entries when doing anti-aliasing.
Skins that use 8bpp bitmaps can call this function with the maximum number
of colors used, and the maximum number of color combinations. The OSD will
then evenly split the available palette entries between the various colors
combinations, so that fonts can be "anti-aliased". By default a total of
10 colors and 10 combinations is assumed.
- The pixel fonts have been completely removed from the VDR source.
- VDR is now "UTF-8 aware". It handles strings according to the character
encoding used on the user's system. All internationalization strings and
incoming SI data are converted to the system encoding.
- Plugins that handle strings need to be aware that on systems with UTF-8
encoding a "character symbol" may consist of more than a single byte in
memory. The functions and macros named Utf8...() can be used to handle
strings without needing to care about the underlying character encoding
(see tools.h for details).
- Even though the weekdays of repeating timers are presented to the user as UTF-8
characters in the OSD, the timers.conf file and the SVDRP timer commands still
use single byte characters ("MTWTFSS") to make sure this information is handled
correctly between systems with different character encodings.
- Added a missing i18n string for "CAM" in the Turkish OSD texts.
- Improved editing strings that are too long to fit into the editable area.
- Changes to the OSD settings in the "Setup/OSD" menu now immediately take effect
when the "Ok" key is pressed.

Have fun!

Klaus

Показать весь код

free-x · 10 Июн 2007

Красивo начал автор =) =) =)

Исходный код

make[1]: Entering directory `/tmp/vdr-1.5.3/PLUGINS/src/skincurses'
g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"skincurses"' -I../../../include skincurses.c
../../../include/vdr/font.h:36: warning: ‘virtual int cFont::Width(uint) const’ was hidden
skincurses.c:24: warning:   by ‘cCursesFont::Width’
skincurses.c: In constructor ‘cCursesFont::cCursesFont()’:
skincurses.c:22: error: no matching function for call to ‘cFont::cFont(NULL)’
../../../include/vdr/font.h:31: note: candidates are: cFont::cFont()
../../../include/vdr/font.h:31: note:                 cFont::cFont(const cFont&)skincurses.c: At global scope:
skincurses.c:30: error: cannot declare variable ‘Font’ to be of abstract type ‘const cCursesFont’
skincurses.c:20: note:   because the following virtual functions are pure within ‘const cCursesFont’:
../../../include/vdr/font.h:36: note:  virtual int cFont::Width(uint) const
../../../include/vdr/font.h:44: note:  virtual void cFont::DrawText(cBitmap*, int, int, const char*, tColor, tColor, int) const
make[1]: *** [skincurses.o] Error 1

Показать весь код

VDR developer version 1.5.x

Поделиться

Похожие темы

Dreambox ONE - pyro branch OE 2.6