Bug#603063: Kdevelop crash (probably) when there are multiple sessions
Hi, Just wanted to add another reason to move to the new upstream 4.1 version. When I open two sessions in kdevelop, sometimes one of them crashes (usually not the one I'm typing in, but the other one). I filed a bug report using kdevelop's crash reporter and one of the developers suggest moving to kdevelop 4.1 to see if the problem is fixed: https://bugs.kde.org/show_bug.cgi?id=262841 I realize crashing is perhaps more serious than a "wishlist", but I know moving to 4.1 takes a lot of effort and in the end, may not even solve my problem... Thanks! Ray -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2d5b29.8050...@cb.k.u-tokyo.ac.jp
Bug#609758: ext. monitor resolution
Package: kdm Version: 4.4.5-6 uname --all Linux b-u6v-d 2.6.32-5-686 #1 SMP Fri Dec 10 16:12:40 UTC 2010 i686 GNU/Linux After a recent battery of upgrades to v. 4.4.5-6 (testing), which included kdm upgrade, ext. monitor cannot switch to 1920xsomething anymore, and the resolution is capped at 1924x768. I am not sure which package is responsible. I am using Asus A6V notebook with ext. monitor. I tried to use reportbug, which remains too hard to use for people like me. b. -- boris -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112175755.600f89e9.bo...@iis.sinica.edu.tw
Bug#609807: konsole: missing Debian menu entry.
Package: konsole Version: 4:4.4.5-1 Severity: normal Hello Debian Qt/KDE Maintainers, konsole is missing a Debian menu entry since Sat, 09 Jan 2010. The file below (/usr/share/menu/konsole) should work: ?package(konsole):\ needs="X11"\ section="Applications/Terminal Emulators"\ title="Konsole"\ command="/usr/bin/konsole" Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112161520.ga19...@yellowpig
Richiedi una visura targhe gratuita
NOVITA' SOFTWARE VISURE PRA Ti piacerebbe sapere a chi è intestata una macchina dal numero di targa ? Con il nostro software è possibile fare vusure al pra in tempo reale, risposta dopo 1 secondo. Una volta acquistato non avrai altri costi e potrai fare tutte le visure che vuoi. Si nessun altro costo, la versione demo ti consente di fare gratis una visura al pra, e la versione acquistabile per 180 euro ti consente di fare tutte le visure che vuoi senza dover pagare niente altro. Su internet sono vari i siti che offrono la possibilità di effettuare visure al pra, ma costano 20 euro per visura, noi con 180 euro ti diamo un software che ti consente di fare tutte le visure che vuoi. Valido sia per le agenzie sia per i semplici curiosi che vogliono sapere a chi è intestata quella macchina. A SOLI 180 EURO SOLO PER OGGI Con soli 180 euro il software sarà tuo e potrai controllare tutte le targhe che vuoi Richiedi una versione dimostrativa del software, potrai fare una visura gratis e se deciderai di comprarlo per 180 euro potrai fare tutte le visure pra che vuoi mailto:online@katamail.com?subject=richiesta_demo_software_visure&body=Richiedo%20la%20Demo%20del%20Software%20Visure%20Pra";> Richiedi la prova gratuita del software che ti consentirà di effettuare una visura gratis, clicca qui
Kate make python code false
Hi!, Kate make python code false, Kate puts the Python source code is not correctly: Kate brings a 2 characters instead of 4 and 8 after a tab! but is not allowed under the Directive http://python.org/dev/peps/pep-0008/ Deutsch: Kate rückt den Python Quelltext nicht richtig ein: Kate rückt 2 Zeichen ein und nach bei 8 ein Tab! aber ist laut Richtlinie nicht erlaubt Dort steht: http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29 Code-Aufbau Einrückung Benutze 4 Leerzeichen pro Einrückungsebene. Für wirklich alten Code, den du nicht in Unordnung bringen willst, kannst du weiterhin 8-Zeichen-Tabulatoren nehmen. Tabulatoren oder Leerzeichen? Vermische nie Tabulatoren und Leerzeichen. Die gebräuchlichste Art in Python einzurücken ist es, nur Leerzeichen zu verwenden. Die zweithäufigste Art ist, nur Tabulatoren zu benutzen. Code, der mit einer Mischung von beidem eingerückt ist, sollte so umgebaut werden, dass nur noch Leerzeichen benutzt werden. Wird der Python-Kommandozeileninterpreter mit der '-t'-Option aufgerufen, so meldet er Warnungen bezüglich Code, der unzulässig Leerzeichen und Tabulatoren mischt. Benutzt man '-tt', werden aus diesen Warnungen Fehler. Diese Optionen sind sehr zu empfehlen! Für neue Projekte werden nur Leerzeichen gegenüber Tabulatoren empfohlen. Die meisten Editoren haben Funktionen, die das einfach machen. Mit freundlichen Grüßen Markus Hackspacher Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101122044.17055.hackspac...@gmx.de
doc-base sections (Re: doc-base revisited)
Robert Luberda wrote: > On 11.01.2011 09:27, Jonathan Nieder writes: >> * The registered documentation is very sparse. It is not obvious >> where any given kind of information is to be found (the categories are >> especially unhelpful and I suspect something more faceted like debtags >> might do a little better). [...] > There's a similar request in bug#171955, and in general it would be nice > to have such thing implemented in both doc-base and frontends like dwww > or dhelp. I'm aware that currently is quite hard for maintainer to > choose the most appropriate section [...] Okay, I'd like to start with this. Surely there is some cross-desktop and cross-distro prior art for documentation categories, right? [1][2][3][4][5][6][7] Oh. Well, what do yelp and khelpcenter4 do, then? yelp has tables of contents in data/toc.xml and data/scrollkeeper.xml, like so: Desktop Welcome to the GNOME Help Browser Accessibility Learn more about making your system more accessible for a range of disabilities GNOME Applications [...] The categories are imho better in many ways than the current list from doc-base.txt (e.g., it has a category for version control, which is what I was last looking for) but they are far from perfect. Seems to be based on the XDG Menu specification[8]. Each document's rarian metadata file includes a semicolon-delimited of categories from that spec. rarian's docs/rar-mdf.xhtml[9] describes the preferred metadata format. omf files work and the documentation says they are preferred for compatibility, too. KHelpCenter uses .desktop files, with a hierarchy of .desktop files determining the hierarchy of documents displayed[10]. The toplevel table of contents: Welcome to KDE KDE Users' Manual Application Manuals (organized according to the menu spec) Control Center Modules KInfoCenter Modules Kioslaves Scrollkeeper - Additional non-KDE documentation Plasma Manual - documentation for the core interface Tutorials Unix Manual Pages (organized by section) Browse Info Pages (uses dir.info) The KDE FAQ Contact Information KDE on the Web Supporting KDE Also notable is the X-DOC-Weight field, which allows "heavier" manuals to be shown below "lighter" documents. This sort of categorization seems quite valuable to me. I would like to separate - tutorials and how-to documents - papers/articles covering some specific topic in depth (still for users) - specifications (file formats, protocols, etc) and design documents - command-line reference (perhaps by requiring that such documentation be provided as man pages/info pages and not be registered separately) - API documentation - user manuals - GUI help collections To start, it seems most important to separate the user manuals and GUI help from the rest. That is somewhat orthogonal to the application hierarchy. This could be achieved by adding a new (optional at first) field to .doc-base files indicating what role the documentation is meant to play. > I agree, it would be a good idea to have some team to review the > doc-base files, especially that something similar is already done for > debconf templates and packages' descriptions. Given a way to register translations (and translations of abstracts) it should be easy to justify "volunteering" debian-l10n-english to help with editorial control over the English version. Maybe even without (would have to ask). Thanks, that was helpful. Jonathan [1] 2003-12-07: discussion on documentation system begins on xdg-list. http://lists.freedesktop.org/archives/xdg/2003-December/001306.html [2] 2003-12-10: "All I really need from the help system is a listing of the documents installed, though having more metadata is always better than less." http://lists.freedesktop.org/archives/xdg/2003-December/001370.html [3] 2004-01-04: "At this point, I've basically agreed on desktop files as the metadata format." http://lists.freedesktop.org/archives/xdg/2004-January/001488.html [4] 2005-05-17: first draft of a help system spec based on .desktop files http://www.freedesktop.org/wiki/Standards/help-system?action=recall&rev=1 [5] 2007-03-22: latest version of that help system spec http://www.freedesktop.org/wiki/Specifications/help-system [6] 2010-04-16: the latest spec, based on a /usr/share/help/ directory. "This does not provide a mechanism for installing metadata files. I'm not really interested in doing that anymore, and nobody else seemed to want it either. I can go into reasons why I don't think it matters if anybody wants to hear it." http://lists.freedesktop.org/archives/xdg/2010-April/011443.html [7] 2010-05-07: more precisely: "My general take is that document formats can embed metadata, so there's no need to provide a separate metadata file. We can look at index.page or index.docbook or
