Bug 22013

Надо подождать. В данный момент в апстриме этот пакет разломан (в одном классе вызываются функции другого класса, но их ещё не существует :) ).

Можно, конечно, собрать не из самой последней ревизии, но тогда будет облом со вторым твоим предложением.

Посмотрю, что на следующей неделе там будет.

Хотя... можно, наверно. проблемный кусок пока просто закомментировать, а спеке добавить TODO, чтобы не забыть...

Это в qtiplot/src/lib/src/DoubleSpinBox.cpp (поскольку в MyParser нет ни SetDecSep, ни SetThousandsSep, толку смысла в добавленном вообще нет)

 void DoubleSpinBox::interpretText()
 {
        bool ok = false;
-       double value = locale().toDouble(text(), &ok);
+       QString s = text();
+       double value = locale().toDouble(s, &ok);
        if (ok && value == d_value)
                return;
 
-       if (ok && setValue(value))
+       if (!ok){
+               MyParser parser;
+               try {
+                       parser.SetExpr(s.toAscii().constData());
+                       parser.SetDecSep(locale().decimalPoint().toAscii());
+                       if (locale().numberOptions () != QLocale::OmitGroupSeparator)
+                               parser.SetThousandsSep(locale().groupSeparator().toAscii());
+
+                       value = parser.Eval();
+               } catch (mu::ParserError &e){
+                       lineEdit()->setText(textFromValue(d_value));
+                       return;
+               }
+       }
+
+       if (setValue(value))
         emit valueChanged(d_value);
     else
         lineEdit()->setText(textFromValue(d_value));

qtiplot-0.9.7.10-alt1.svn20091021 -> sisyphus:

* Thu Oct 22 2009 Eugeny A. Rostovtsev (REAL) <real at altlinux> 0.9.7.10-alt1.svn20091021

- Version 0.9.7.10 (ALT #22013)

Во-первых, огромное спасибо за проделанную работу! Я вижу, у вас лучше получается сопровождать QtiPlot, чем у меня :) К сожалению, в данную сборку закралась ошибка. Почему-то в /usr/share/qtiplot/translations оказались файлы с расширением .ts (исходники переводов), а не сами переводы (.qm), из-за чего исчез перевод интерфейса. Кроме того, у меня вызывает некоторое недоумение вынос переводов в пакет qtiplot-data, вроде файлы локализации относятся к самой программе, а не дополнениям.

"Я вижу, у вас лучше
получается сопровождать QtiPlot, чем у меня"

У других бы получилось ещё лучше: мне скучно этим пакетом заниматься, но потребность в нём есть, потому терплю. Тем более сам пакет довольно прост, единственный БОЛЬШОЙ минус: долго собирается.

"Почему-то в /usr/share/qtiplot/translations оказались файлы с
расширением .ts (исходники переводов), а не сами переводы (.qm)"

.qm почему-то исчезли (в смысле после полной сборки их нет), попробую поискать, что там стряслось, не знаю, правда, дорвусь ли на выходных... (ох, и не надоело ли апстриму чуть ли не каждую неделю менять процесс сборки; у самих-то крыша не течёт от такого? :-D )

"Кроме того, у меня вызывает некоторое недоумение
вынос переводов в пакет qtiplot-data, вроде файлы локализации относятся к самой
программе, а не дополнениям."

Я в qtiplot-data вынес все независимые от архитектуры файлы, ну и, соответственно, переводы тоже к таким относятся. И qtiplot-data - это не дополнение вовсе, его появление вызвано гавканьем repocop на слишком большой объём в /usr/share у НЕnoarch пакета. Плюс вот это (для пакета qtiplot): Requires: %name-data = %version-%release

qtiplot-0.9.7.10-alt1.svn20091021.1 -> sisyphus:

* Fri Oct 23 2009 Eugeny A. Rostovtsev (REAL) <real at altlinux> 0.9.7.10-alt1.svn20091021.1

- Added missing translation files (ALT #22013)

(В ответ на комментарий №6)
> "Я вижу, у вас лучше
> получается сопровождать QtiPlot, чем у меня"
> 
> У других бы получилось ещё лучше: мне скучно этим пакетом заниматься, но
> потребность в нём есть, потому терплю. Тем более сам пакет довольно прост,
> единственный БОЛЬШОЙ минус: долго собирается.

У меня к нему было аналогичное отношение. Я неплохо разбираюсь в коде на C/gtk, или на крайний случай C++/gtkmm, но qt для меня лес тёмный... А по работе приходится днями из него не вылезать.

> 
> "Почему-то в /usr/share/qtiplot/translations оказались файлы с
> расширением .ts (исходники переводов), а не сами переводы (.qm)"
> 
> .qm почему-то исчезли (в смысле после полной сборки их нет), попробую поискать,
> что там стряслось, не знаю, правда, дорвусь ли на выходных... (ох, и не надоело

Там это периодически случается...

> ли апстриму чуть ли не каждую неделю менять процесс сборки; у самих-то крыша не
> течёт от такого? :-D )

Ой, не знаю, что там с крышей у апстрима твориться... С одной стороны надо быть незаурядным программистом, чтобы написать подобный проект (а, как я могу судить, Ион там делает львиную долю работы в одиночку), но при этом он умудряется придерживаться какого-то невменяемо-корявого стиля кодирования (начиная от атрибута исполняемости у всех исходников и кончая безумной системой сборки).

> 
> "Кроме того, у меня вызывает некоторое недоумение
> вынос переводов в пакет qtiplot-data, вроде файлы локализации относятся к самой
> программе, а не дополнениям."
> 
> Я в qtiplot-data вынес все независимые от архитектуры файлы, ну и,
> соответственно, переводы тоже к таким относятся. И qtiplot-data - это не
> дополнение вовсе, его появление вызвано гавканьем repocop на слишком большой
> объём в /usr/share у НЕnoarch пакета. Плюс вот это (для пакета qtiplot):
> Requires: %name-data = %version-%release

Тогда понятно. Интересно, а на обычные файлы .mo (локализация gettext) repocop тоже гавкает? Так в недалёком будущем можно придти к отрыванию локализации всех пакетов в отдельные noarch. В принципе файлы с цветовыми схемами можно было бы вынести в отдельный пакет qtiplot-colormaps, т.к. они обновляются гораздо реже, чем сам qtiplot и к тому же не всем нужны (только тем, кто в нём рисует трёхмерные поверхности).

А вообще огромное спасибо ещё раз! С qtiplot'ом вы меня сейчас реально выручаете: работать в нём нужно, а времени для борьбы с апстримом нет.