Re: [kde] How to add a language translation from svn?
As Kevin said, you must "translate" PO files into (binary) MO files. msgfmt utility (from gettext package) might be used to do that: $ msgfmt -o file.mo file.po Then, MO files should be put into /usr/share/locale/ta/LC_MESSAGES/ directory. Additionally, you need /usr/share/locale/ta/entry.desktop file. Without it, you won't be able to pick up Tamil from list of existing languages. Simplified file content is below: [KCM Locale] Name=Tamil Name[ta]=Tamil in Tamil On my system, localization files are owned by user root, group root, and have 644 permissions. Hope that helps -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Dolphin does not show "extract here" menu
Dnia 2014-05-16, o godz. 11:55:47 "Carlos Luna" napisał(a): > Yes Mr Frank Steinmetzger I have chech almost all the options into > Dolphin settings, as I write earlier the option to uncompress > for .rar, tar.gz, 7z and so on run nice, they are shown on the menu, > but for ZIP not, the trounble is just and only for zip. Do you happen to use Debian? Because there is a bug in Debian package (probably a honest mistake) that causes exact issue that you are describing, that is Dolphin does not show "extract here" for ZIP files. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746730 for details and fix that you can apply on your system. If you are NOT running Debian, then applying these changes might not be the best idea. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] What is baloo_file_extractor and why is it humping my hard drive?
Dnia 2014-04-18, o godz. 10:44:59 Kevin Krammer napisał(a): > There was a quite interesting Google Summer of Code project last year > on providing some advanced UI pieces that application developers can > use but the move to Baloo probably makes it necessary to at least > port this before it can be provided as a general library. > > http://community.kde.org/GSoC/2013/StatusReports#Denis_Steckelmacher Porting effort has already started, by the same guy: http://steckdenis.be/post-2014-03-10-porting-the-nepomuk-query-parser-to-baloo.html -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] KDE's rough edges... what are your experiences?
Dnia 2013-10-29, o godz. 07:13:37 Draciron Smith napisał(a): > The whole single click thing which cannot be modified too a > double click makes file transfers from disks an effort in frustration. Unless something changed in 4.11 (I am still using 4.10), you can go to configuration dialog in Dolphin and there, in Navigation pane, make double click open files (single click selects, then). -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] KWallet: what are "local passwords"?
Dnia 2013-09-27, o godz. 21:12:58 Kevin Krammer napisał(a): > Which is likely also false, I would at least expect Rekonq to do that > as well and I hear Chrome and Chromium can access KWallet also. I can confirm that both Rekonq and Chromium do use KWallet to store passwords for website forms. As far as latter goes, it can also use GNOME keyring or internal storage. It can be configured with command line switch or some option deep inside advanced preferences, don't remember which one. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Virtually Invisible Panel Clock
On 31/05/2013 at 03:22, Felix Miata wrote: > $SUBJECT was meant literally: > http://fm.no-ip.com/SS/kdemageialowfipanelclock1200-120.png > > Not nice, and looks the same in 4.10.3 in Fedora and openSUSE. Yes, I can reproduce. It seems that default plasma theme provides transparent panels and white text. It does look nice if you use dark wallpaper (which perhaps should be default). If you change wallpaper to lighter or white, reading may be difficult. Perhaps there is not much that can be done on plasma level. It should know what color wallpaper is and change theme color accordingly (much as Windows 8 does, I believe). Until then, you can simply right click on clock → Digital Clock Setting. In Appearance "tab" there is checkbox labeled "Custom font color". Just check it and change color to black (or anything you prefer). -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Yet another failed KDE release?
On 07/05/2013 at 18:06, Doug wrote: > I thought KDE was short for "K Desktop Environment," a replacement for a > Unix CDE--Common Desktop Environment? It is not for over a three years now. KDE is simply KDE and the meaning is "entire community". Software is called KDE SC, which means KDE *Software Compilation* - emphasis is put on fact that there are many programs, not just one. You can read more about it on: <http://dot.kde.org/2009/11/24/repositioning-kde-brand> But yes, KDE (community) has failed to bring this distinction to wider audience. Hell, I bet that even among long-term KDE community members there are many people not aware of "official" meaning of KDE and KDE SC. Of course there are much bigger problems in both KDE and KDE SC, so not wasting time on trying to teach people differences between two terms is not necessarily a bad thing. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Yet another failed KDE release?
On 22/03/2013 at 13:28, Ingo Malchow wrote: > This is an assumption and hopefully no dev ever thinks the same way. > Config files are text files and CAN be edited by anyone. And guess what, > they are quite often edited by hand. You need to think in the big picture. Yes, I have made an assumption that *using* KDE SC without thinking much about software internals and hand-crafting config files is supported use-case. As I understand, it is not; non-compatibility with previous major release is not considered bug. I stand corrected. It is clear to me now, that I have tried to make KDE SC something it was never intended to be. I just want to get my (unrelated to KDE SC) work done in environment that corresponds with my needs and habits. With regret I say that I am not your target user. Sorry I have bothered you. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Yet another failed KDE release?
On 22/03/2013 at 12:34, Myriam Schweingruber wrote: > It is almost impossible, since the user can dramatically modify the > original configuration and automating the process of wading through > often illogical configuration files with triple definitions and > contradictory instructions set by the user is a a lot of work I think there are two important things to note: (1) config files are created by KDE SC, not by users with text editors (2) these config files are already read and understood by current KDE SC releases. If they contain illogical on contradictory instructions, it's KDE SC configuration GUI who put it there. So, maybe configuration GUI should be fixed to ensure that config files are unambiguous? Sorry, but I do not believe that it's impossible to read and understand config file that were read and understood correctly by previous version of software. It is obviously matter of developers priorities. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Yet another failed KDE release?
On Fri, Mar 22, 2013 at 8:08 AM, Nikos Chantziaras wrote: > The biggest issue is that with each new release, there's more glitches > while the old ones are still there. On 22/03/2013 at 11:38, Myriam Schweingruber wrote: > And make sure you ALWAYS test with a new user or move the old config files > elsewhere when you do a major upgrade. Myriam, this is exactly Nikos point. Old config files laying around causes various issues with KDE SC. By encouraging him to triage bugs on fresh config, you admit that. I think that this is huge drawback of KDE SC. As user, I am forced to recreate my carefully crafted configuration from scratch with each major update. Do I remember what exactly did I change and where? No, I have better things to do. Starting from fresh config, I only discover that something I am used to does not work. Then I go into System settings and try to find relevant option. Recreating configuration is not matter of two or three hours; it's matter of days during which my work is not effective, because I am constantly disturbed with changes I have to make. Or I can save myself some hustle and start from fresh config, but copy some old files over. But this way I am forced to dive into KDE SC internals and understand purpose of each file (to be able to judge whether I should copy it or not). Do I want to? No, I have other things to do. Honestly, why can't KDE SC support seamless update from previous major release? Is it too much work to rewrite config files whose format has changed? -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Force regeneration of thumbnails ?
On 21/10/2012 at 14:19, Sven wrote: > Perhaps erasing the content of the ~/.thumbnails directory solve your > problem ? But you should note that this will remove ALL thumbnails, not only for given directory. Since thumbnails cache is, well, cache, and can be easily regenerated, it isn't much of a problem. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] How to install Okular 0.15?
On 27/08/2012 at 12:01, Marius Hofert wrote: > When will 0.15 be available via package managers? It already is. You will find it in kubuntu-ppa/backports PPA. If you need one specific feature that Okular 0.15 brings, which is a reason most people bother to upgrade in the first place - saving annotations in PDF - then you also need libpoppler 0.20. To get it, you must use Quatzal Quental (12.10) repositories. 12.10 is currently in alpha stage, but first beta is scheduled for 6 September. If you are going for Ubuntu 12.10 repos, then you don't need Kubuntu PPA mentioned above. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] How to install KDE 4.9 on Debian Squeeze
On 20/08/2012 at 19:02, andre_deb...@numericable.fr wrote: > Actually, on Wheezy (unstable) the package KDE = 4.9 or less ? On both Wheezy and unstable there are 4.8.4 packages. Wheezy will ship with it [0], and due to Debian freeze policy, we won't see 4.9 in unstable. It may end up in semi-official repository [1] sometime during a freeze, but it has never been confirmed (I wouldn't count on it). It has been confirmed that KDEPIM from 4.8.4 will be packaged [2] - look at it in this external repository or in experimental. If you need to use KDE 4.9, you may: - compile it yourself. Perhaps upgrade to Wheezy before, since it has newer Qt and Qt development packages available. - use another distribution. Kubuntu is Ubuntu-based (which, in turn, is Debian-based), so it has administrative tools you should be familiar with. There are also openSUSE, Arch, Gentoo and many others that has KDE 4.9 available. [0] http://lists.debian.org/debian-kde/2012/05/msg00066.html [1] http://qt-kde.debian.net/ [2] http://lists.debian.org/debian-kde/2012/06/msg00047.html -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] How to install KDE 4.9 on Debian Squeeze
On 20/08/2012 at 14:55, "dE ." wrote: > 4.9 will be available on Debian testing once wheezy freezes. I suppose you meant "releases". Wheezy is frozen for almost two months right now. We can expect release of Wheezy around January/February 2013. At this time, KDE 4.10 will be around a block. So Debian KDE maintainers might as well decide to skip 4.9 entirely, pretty much as they did with 4.5. Or do you have any official statement available? If so, I am most eager to read it. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] How to install KDE 4.9 on Debian Squeeze
On 20/08/2012 at 12:52, andre_deb...@numericable.fr wrote: > On Debian Squeeze : > # add-apt-repository ppa:kubuntu-ppa/backports -y > kubuntu-ppa/backports > Executing: > gpg --ignore-time-conflict --no-options --no-default-keyring > --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg > --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg > --keyserver keyserver.ubuntu.com --recv-keys > > Debian seems not accepted to work with a backport Ubuntu ... This creates file /etc/apt/sources.list.d/kubuntu-ppa-backports-wheezy.list with content like this: deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu wheezy main deb-src http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu wheezy main Since there is no wheezy directory on kubuntu-ppa launchpad site, apt-get update will fail. If you care, you must use correct sources.lists entries: (for Ubuntu 12.04:) deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu precise main deb-src http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu precise main OR (for Ubuntu 11.10:) deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu oneiric main deb-src http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu oneiric main Please note that these packages were made with Ubuntu in mind and perhaps no one has ever tested them on Debian. It is unlikely they will break your system, but most certainly they may break your KDE installation. Pay special attention to any warning messages you may encounter while installing these packages. Oh, and get rid of your current KDE installation before you proceed. Almost certainly these packages are in conflict with each other, even if no one has marked them so. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Dots in filenames and automatic file extension completion
On 02/08/2012 at 05:35, "dE ." wrote: > Actually this's a very small bug. You can just type the name with the > extension to solve the problem. > > And considering this minor nature, this wont be fixed by the LO team for > years (cause they've much bigger bugs to take care of). Sorry, but I don't see your point here. What's the difference if this is minor or huge bug? Bug is a bug, developers should be aware of it. Since they prioritize bug reports, they will not act upon each bug immediately, but they should at least know where their software has rough edges. And personally, I would rather see this fixed in few years than never. By the way, as you can see in LO bug tracker (link is in one of previous posts), they actually did commit change that is supposed to fix that (I did not had opportunity to see if this fix really works). -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Dots in filenames and automatic file extension completion
On 30/07/2012 at 15:50, "dE ." wrote: > You're using Gentoo right? I'm, with (~amd64) libreoffice 3.5.5.3. KDE > is at 4.8.4. No, I am using Debian testing (Wheezy) right now. Sorry if I forgot to mention that. I have the same architecture, LO and KDE versions as you do. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Dots in filenames and automatic file extension completion
On 26/07/2012 at 17:12, "dE ." wrote: > You may like to disable KDE/QT dialogues in libreoffice-KDE by tools > > options > [check] Use libreoffice dialogs. Then I won't have access to "Places". Yes, I quite complain ;) . The problem is that each method has drawbacks and I have to choose lesser evil, which I hate. > Also this problem does not persist in my setup using KDE dialogues. Could you elaborate? What LO/KDE versions? What distribution? How was LO/KDE installed? Can you point out where exactly your results differs from mine (please see tables in first message in this thread and table available in LO bug report[1])? It would be interesting to know what are differences between mine and your setup and where does results differ. [1] https://bugs.freedesktop.org/show_bug.cgi?id=52546 -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Dots in filenames and automatic file extension completion
Thanks for your replies. I have sent bug report to LO. It can be found here: https://bugs.freedesktop.org/show_bug.cgi?id=52546 Feel free to provide any information I might have missed that you find important. Let's hope they will look into this soon. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Dots in filenames and automatic file extension completion
Thanks for your reply. I'm not sure if I understood everything correctly (may be my English, though). That's true, that "Automatically select filename extension" is antoher factor that I should have taken into account. I forgot about it, sorry. My test was run with that checkbox enabled (which I believe is default anyway). On 25/07/2012 at 10:09, Duncan <1i5t5.dun...@cox.net> wrote: > a) Does LO use native desktop file-save dialogs, kde's file-save > dialogs on kde, gtk's on gtk, and either gtk's or its own on > bare X11? Yes, they do. KDE file dialog on KDE Plasma, GTK file dialog on GNOME and others (e.g. Openbox) and pure X11/their own (I'm not sure, I don't know if I have ever seen pure X11 file dialog) when no KDE/GTK is available. > b) For kde apps, and thus LO too if it uses native kde file dialogs > on kde, does the suggested save-as name change, based on the > filetype filter and/or whether the "automatically select filename > extension" checkbox is selected in the save-as dialog? Yes, it does change. It looks like this: Automatic... checked? 1.2.3.4 1.2.3.4.odt no1.2.31.2.3.4 yes 1.2.pdf 1.2.3.pdf (I tried "Export to PDF" function.) For me, it looks pretty much that both KDE and LO strips extension from filename. If I disable KDE automatic filename extension it does not strip it, but I have one component stripped anyway. Unfortunately, disabling "Automatically select filename extension" checkbox is working system-wide, at least on 4.8.4. Without this drawback, it would be nice workaround (but I have to think what is more frustrating - handicapped filenames in LO or being forced to type file extension each time). I believe that my questions #1 and #2 are pretty much answered (but any other comments are welcome). Any comments about my question #3? -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Dots in filenames and automatic file extension completion
Each time I edit some file with dots in name in LibreOffice, I got major
headache. When saving as or exporting file, LO strips too many components from
filename - not only extension - producing handicapped filenames. Especially my
university papers are tend to be named "M. Zalewski - paper name.odt" and when
I export them to PDF to send to lecturer, LO proposes just "M.pdf".
This has been reported to LO devs[1], but they say that they will not do
anything about it, as this is KDE issue.
So I decided to make experiment and check behaviour of different applications
for files with dots in names. I copied one file (text file, JPG image and PDF
document, depending on application) to two names: 1.2.3.4 and 1.2.3.4.
{txt,jpg,pdf}. Then I opened each file in application, clicked "Save as" and
see what filename was proposed in save dialog.
Results:
program file with ext file without ext
LibreOffice (kde)1.2.3.odt 1.2.odt
LibreOffice (gtk)1.2.3.4 1.2.3
LibreOffice (none) 1.2.3.4 1.2.3
kwrite 1.2.3.4.txt 1.2.3.4
leafpad 1.2.3.4.txt 1.2.3.4
Okular 1.2.3.4.pdf 1.2.3.4
Gwenview 1.2.3.4.jpg 1.2.3.jpeg
KolourPaint 1.2.3.4.jpg 1.2.3.jpeg
GIMP 1.2.3.4.jpg 1.2.3.4
LO dev claim is only half-true - under KDE, behaviour is inconsistent. Kwrite
and Okular preserves filenames without extensions, while Gwenview and
KolourPaint do not. This may or may not be related to fact, that Gwenview and
KolourPaint has ability to save file in different format (select extension from
drop-down list), while Okular and KWrite do not.
Also, LO under KDE behaves clearly different than LO under GTK or pure X11, so
there are definitely bits of KDE involved.
My questions are:
1. Can I, as a user, do something about it? Some work-around on KDE level?
Apart from avoiding dots in filenames, of course.
2. Can someone with deeper KDE knowledge explain this? What is really going on
under the hood? Why LO under KDE, Okular and Gwenview behave differently?
3. Where, if anywhere, should I report this issue? I understand that LO devs
claim that this is KDE issue and KDE devs can claim this is LO issue, but it's
users that loose here. Maybe if KDE offer some function that programs can use
to tell KDE that it should leave file extension alone, LO devs will be willing
to change their codebase. I am willing to try and serve as proxy between KDE
and LO developers, if that's needed. Since I am not a programmer and don't
know C/C++, I can't propose patches that will fix it.
Thanks in advance
[1] https://bugs.freedesktop.org/show_bug.cgi?id=45764
--
Best regards
Mirosław Zalewski
___
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
Re: [kde] plasma "upside down" ...
On 13/07/2012 at 19:44, Hans Muecke wrote: > Anyone have an idea what went wrong here and how to possibly correct it? If it's not X configuration, I bet something is with ~/.kde/share/config/krandrrc file. Try logging out and removing it. -- Best regards Mirosław Zalewski ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
