Usage of env and shutdown directories of KDE
Hi, I've confused about the path of the env and shutdown directories of KDE. In startkde script, env directory is sourced like this: libpath=`kde4-config --path lib | tr : '\n'` for prefix in `echo $libpath | sed -n -e 's,/lib[^/]*/,/env/,p'`; do for file in $prefix*.sh; do test -r $file . $file done done So, if a distro uses /usr/lib as libdir, sh files are searched in ~/.kde and /usr/env directories since kde4-config is called with --path lib parameters. This is the case in Pardus and Kubuntu 10.10. openSUSE patched[1] startkde to source /usr/share/kde4/env directory. Same thing is valid for shutdown directory. Is this the intended behaviour? As far as I can see, there is no such entry in kde4-config like kde4-config --path env. That kind of path variable would be useful. [1] https://build.opensuse.org/package/view_file?file=startkde.diffpackage=kdebase4- workspaceproject=openSUSE%3AFactorysrcmd5=799755ebf5e167f59cc2f50cb1ea11b2 -- Gökçen Eraslan signature.asc Description: This is a digitally signed message part.
Re: Usage of env and shutdown directories of KDE
On Monday 25 April 2011, Gökçen Eraslan wrote: Hi, I've confused about the path of the env and shutdown directories of KDE. In startkde script, env directory is sourced like this: libpath=`kde4-config --path lib | tr : '\n'` for prefix in `echo $libpath | sed -n -e 's,/lib[^/]*/,/env/,p'`; do for file in $prefix*.sh; do test -r $file . $file done done So, if a distro uses /usr/lib as libdir, sh files are searched in ~/.kde and /usr/env directories since kde4-config is called with --path lib parameters. This is the case in Pardus and Kubuntu 10.10. openSUSE patched[1] startkde to source /usr/share/kde4/env directory. Same thing is valid for shutdown directory. Is this the intended behaviour? As far as I can see, there is no such entry in kde4-config like kde4-config --path env. That kind of path variable would be useful. Maybe. In any case, data appears to be a better choice than lib. At least on openSUSE. # kde4-config --path data ~/.kde/share/apps/:/usr/share/kde4/apps/:/etc/kde4/share/apps/ Regards, Ingo signature.asc Description: This is a digitally signed message part.
Replacement for Qt's Undo Framework
Hi,
The Qt's Undo Framework (QUndoCommand, QUndoStack, QUndoGroup,
QUndoView) has a few oddities:
1. The names of undo actions can only have a predefined prefix
(https://bugs.kde.org/show_bug.cgi?id=253459),
2. You can't use different strings for the name of undo action (Edit
- Undo/Redo [some action]) and for the items in the undo history
(there is such panel, for example, in Step and Krita). The reason for
having different strings is to make grammatical cases of the names of
actions consistent with the context (in Russian and a few other
languages you should put %1 in accusative case in Undo %1).
If I'm not mistaken, those problems can't be solved by just deriving
your own classes from QUndo*, because you need to override methods
like createUndoAction which are not virtual (sure, you can name
those methods differently, but then other problems may arise).
The solution is to fork QUndo* classes and fix the problems in the new
classes, so did I:
https://github.com/aspotashev/libkundo2
(the code looks like garbage, I only made it working, but didn't try
to clean it up)
At the first glance, the only way to use two strings for every
UndoCommand is to add yet another argument to the constructor of
UndoCommand. But then a huge amount of code would need changes, that's
not very good. Also, most languages don't really need different names
for undo actions and items in undo history.
I kept the arguments of UndoCommand() the same, but now if you put
something like Create a document|-|creation of a document as the
text into the constructor (or translate it with a similar string
with |-|), you'll get Create a document as the name of an item in
Undo History panel, and the Undo ... menu item will be called Undo
creation of a document.
Screenshots:
http://ompldr.org/vOGYxaQ -- translation in Lokalize (into Russian)
http://ompldr.org/vOGYxag -- Step using different translations for
Undo ... command and undo history.
The patch I used for Step is attached.
What do you think about inclusion of KUndo*2 into kdelibs?
--
Alexander Potashev
From aec3a9f2fa6c16d46a5de10bb29441007245c676 Mon Sep 17 00:00:00 2001
From: Alexander Potashev aspotas...@gmail.com
Date: Mon, 25 Apr 2011 19:46:51 +0400
Subject: [PATCH] use libkundo2
---
step/CMakeLists.txt |1 +
step/mainwindow.cc |4 ++--
step/undobrowser.cc |4 ++--
step/undobrowser.h |4 ++--
step/worldmodel.cc | 16
step/worldmodel.h | 10 +-
6 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/step/CMakeLists.txt b/step/CMakeLists.txt
index 4d571ea..e26dcd3 100644
--- a/step/CMakeLists.txt
+++ b/step/CMakeLists.txt
@@ -65,6 +65,7 @@ include_directories(${CMAKE_CURRENT_SOURCE_DIR})
kde4_add_executable(step ${step_SRCS})
target_link_libraries(step
stepcore
+kundo2
${KDE4_KHTML_LIBS}
${KDE4_KNEWSTUFF3_LIBS}
${QT_QTOPENGL_LIBRARY}
diff --git a/step/mainwindow.cc b/step/mainwindow.cc
index fdc0e50..cdc5169 100644
--- a/step/mainwindow.cc
+++ b/step/mainwindow.cc
@@ -177,9 +177,9 @@ void MainWindow::setupActions()
connect(worldModel-undoStack(), SIGNAL(canRedoChanged(bool)), actionRedo, SLOT(setEnabled(bool)));
connect(worldModel-undoStack(), SIGNAL(canUndoChanged(bool)), actionUndo, SLOT(setEnabled(bool)));
connect(worldModel-undoStack(), SIGNAL(cleanChanged(bool)), this, SLOT(updateCaption()));
-connect(worldModel-undoStack(), SIGNAL(undoTextChanged(const QString)),
+connect(worldModel-undoStack(), SIGNAL(undoActionTextChanged(const QString)),
this, SLOT(undoTextChanged(const QString)));
-connect(worldModel-undoStack(), SIGNAL(redoTextChanged(const QString)),
+connect(worldModel-undoStack(), SIGNAL(redoActionTextChanged(const QString)),
this, SLOT(redoTextChanged(const QString)));
actionDelete = actionCollection()-addKAction(edit_delete, worldModel, SLOT(deleteSelectedItems()));
diff --git a/step/undobrowser.cc b/step/undobrowser.cc
index 05e6fdc..7979f44 100644
--- a/step/undobrowser.cc
+++ b/step/undobrowser.cc
@@ -20,7 +20,7 @@
#include undobrowser.moc
#include worldmodel.h
-#include QUndoView
+#include kundoview2.h
#include KUrl
#include KIcon
#include KLocale
@@ -28,7 +28,7 @@
UndoBrowser::UndoBrowser(WorldModel* worldModel, QWidget* parent, Qt::WindowFlags flags)
: QDockWidget(i18n(Undo history), parent, flags), _worldModel(worldModel)
{
-_undoView = new QUndoView(_worldModel-undoStack(), this);
+_undoView = new KUndoView2(_worldModel-undoStack(), this);
setWidget(_undoView);
}
diff --git a/step/undobrowser.h b/step/undobrowser.h
index a60d679..c05629d 100644
--- a/step/undobrowser.h
+++ b/step/undobrowser.h
@@ -22,7 +22,7 @@
#include QDockWidget
class WorldModel;
-class QUndoView;
+class KUndoView2;
class KUrl;
class UndoBrowser: public QDockWidget
@@ -39,7 +39,7 @@ public slots:
protected:
WorldModel* _worldModel;
-
Re: Usage of env and shutdown directories of KDE
On Monday 25 April 2011, Gökçen Eraslan wrote: So, if a distro uses /usr/lib as libdir, sh files are searched in ~/.kde and /usr/env directories since kde4-config is called with --path lib parameters. This is the case in Pardus and Kubuntu 10.10. openSUSE patched[1] startkde to source /usr/share/kde4/env directory. Same thing is valid for shutdown directory. Is this the intended behaviour? As far as I can see, there is no such entry in kde4-config like kde4-config --path env. That kind of path variable would be useful. the system locations were never meant to be used with that. it was a quick hack in the first place. if you feel like overengineering it thoroughly, be my guest. but don't break compatibility, i.e., list the current user locations. On Mon, Apr 25, 2011 at 07:22:23PM +0200, Ingo Klöcker wrote: Maybe. In any case, data appears to be a better choice than lib. At least on openSUSE. if anything, then config.
Re: Usage of env and shutdown directories of KDE
On Monday 25 April 2011, Oswald Buddenhagen wrote: On Monday 25 April 2011, Gökçen Eraslan wrote: So, if a distro uses /usr/lib as libdir, sh files are searched in ~/.kde and /usr/env directories since kde4-config is called with --path lib parameters. This is the case in Pardus and Kubuntu 10.10. openSUSE patched[1] startkde to source /usr/share/kde4/env directory. Same thing is valid for shutdown directory. Is this the intended behaviour? As far as I can see, there is no such entry in kde4-config like kde4-config --path env. That kind of path variable would be useful. the system locations were never meant to be used with that. Apparently, the guys at openSUSE don't know this. :-) it was a quick hack in the first place. if you feel like overengineering it thoroughly, be my guest. but don't break compatibility, i.e., list the current user locations. On Mon, Apr 25, 2011 at 07:22:23PM +0200, Ingo Klöcker wrote: Maybe. In any case, data appears to be a better choice than lib. At least on openSUSE. if anything, then config. Yeah, or that (even though I don't see why config should be better than data). If anything, then env is very close to xdgconf- autostart, but that one doesn't include something like /usr/share/kde4/*. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Deploying new kdelibs classes
A Dissabte, 23 d'abril de 2011, Jaroslaw Staniek va escriure: Aurélien, I am writing regarding http://agateau.wordpress.com/2011/04/21/kde-ux-2011/ One thing, about deploying the kmessagewidget (and similar things) in kdelibs. If it's part of kdelibs 4.7 or something, apps that support kdelibs 4.7 would have to fork it (unless distro backports given classes to previous kdelibs but this it very bad idea and technically and coordination-wise). Well, that makes sense, if you want to use a new feature, you have to depend on a new version, why you do not think that's acceptable? Albert
Re: Deploying new kdelibs classes
On 23/04/2011 23:22, Jaroslaw Staniek wrote: Aurélien, I am writing regarding http://agateau.wordpress.com/2011/04/21/kde-ux-2011/ One thing, about deploying the kmessagewidget (and similar things) in kdelibs. If it's part of kdelibs 4.7 or something, apps that support kdelibs 4.7 would have to fork it (unless distro backports given classes to previous kdelibs but this it very bad idea and technically and coordination-wise). I agree it is a problem. I used to copy relevant classes into Gwenview code when it was a 3rd-party application. How to solve that? I am thinking about releasing additions to kdelibs as separate libraries like kdelibs47.so etc. and then merging only in 5.0. That would mean no new classes in what I would call kdelibs46 (ie, current libkdecore, libkdeui...), all new classes go to kdelibs47, then when we start KDE 4.8, kdelibs47 is frozen for new classes, which go into kdelibs48, is this correct? It certainly looks clever. I am just worried about the cost for loading these additional libraries? Would loading more libraries impact application or desktop startup time? Aurélien
Re: Replacement for Qt's Undo Framework
A Dilluns, 25 d'abril de 2011, Alexander Potashev va escriure: Hi, The Qt's Undo Framework (QUndoCommand, QUndoStack, QUndoGroup, QUndoView) has a few oddities: The solution is to fork QUndo* classes and fix the problems in the new classes, so did I: https://github.com/aspotashev/libkundo2 (the code looks like garbage, I only made it working, but didn't try to clean it up) I kept the arguments of UndoCommand() the same, but now if you put something like Create a document|-|creation of a document as the text into the constructor (or translate it with a similar string with |-|), you'll get Create a document as the name of an item in Undo History panel, and the Undo ... menu item will be called Undo creation of a document. This approach seems a bit too fragile to wrong/careless translations, though i guess we can always add it to the pology checks What do you think about inclusion of KUndo*2 into kdelibs? Maybe it would make sense you to improve your code to a point to are happy with it before asking for inclusion? Albert
Re: kio/scheduler: Does not compile with Qt from 4.8 branch
Le Monday 25 April 2011, Michael Pyne a écrit : On Sunday, April 24, 2011 16:42:22 Christoph Feck wrote: On Sunday 24 April 2011 15:04:38 Thiago Macieira wrote: Olivier, these are your moc changes. Given that Q_PRIVATE_SLOT is a private definition, shouldn't we rather fix the code in KDE? Perhaps, but let's let the developers making the changes verify that this was an intended side effect of the change. ;) Exactly, we rather be aware of breakage, so we can try not to break anything. In this case, we have to see if we can fix it in Qt. I do not see any solution on top of my head. We have to discuss if it is ok to break this use case if there is no solution. But it is true that this is use of private API, over which we do not support compatibility, so i think we may keep this change in Qt, and the change can be fixed in KDE
Re: Replacement for Qt's Undo Framework
Le Monday 25 April 2011, Alexander Potashev a écrit : Hi, The Qt's Undo Framework (QUndoCommand, QUndoStack, QUndoGroup, QUndoView) has a few oddities: 1. The names of undo actions can only have a predefined prefix (https://bugs.kde.org/show_bug.cgi?id=253459), 2. You can't use different strings for the name of undo action (Edit - Undo/Redo [some action]) and for the items in the undo history (there is such panel, for example, in Step and Krita). The reason for having different strings is to make grammatical cases of the names of actions consistent with the context (in Russian and a few other languages you should put %1 in accusative case in Undo %1). If I'm not mistaken, those problems can't be solved by just deriving your own classes from QUndo*, because you need to override methods like createUndoAction which are not virtual (sure, you can name those methods differently, but then other problems may arise). The solution is to fork QUndo* classes and fix the problems in the new classes, so did I: https://github.com/aspotashev/libkundo2 (the code looks like garbage, I only made it working, but didn't try to clean it up) At the first glance, the only way to use two strings for every UndoCommand is to add yet another argument to the constructor of UndoCommand. But then a huge amount of code would need changes, that's not very good. Also, most languages don't really need different names for undo actions and items in undo history. I kept the arguments of UndoCommand() the same, but now if you put something like Create a document|-|creation of a document as the text into the constructor (or translate it with a similar string with |-|), you'll get Create a document as the name of an item in Undo History panel, and the Undo ... menu item will be called Undo creation of a document. Screenshots: http://ompldr.org/vOGYxaQ -- translation in Lokalize (into Russian) http://ompldr.org/vOGYxag -- Step using different translations for Undo ... command and undo history. The patch I used for Step is attached. What do you think about inclusion of KUndo*2 into kdelibs? I have not seen the details about KUndo2 yet, but what are the reasons that keep you from improving QUndo in Qt? Is there technical reasons? or just political issues? Because this KUndo2 things are just against the others goal: http://community.kde.org/KDE_Core/QtMerge
