22 Feb
2014
22 Feb
'14
7:53 a.m.
Slavek, All,
One of the traditional KDE applications that I just tried to find in TDE to
look through the ~/.trinity/share/apps data was 'kxmledit'. It is a good/solid
xml editor. The kde3 version is 1.14. You can get it here:
http://downloads.sourceforge.net/project/kxmleditor/KXMLEditor/1.1.4/kxmled…
It is a small package and actually one 'worth' adding. Let me know what you
think. I would like to see TDE at a minimum have:
text editor (done - kate,kwrite,kedit,quanta+)
hex editor (done - khexedit)
xml editor (need...)
For those not familiar with it, here is a screenshot from suse/kde3:
http://www.3111skyline.com/dl/dt/trinity/ss/kxmleditor-needed.jpg
--
David C. Rankin, J.D.,P.E.
22 Feb
22 Feb
2:39 p.m.
New subject: R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
Added to bugszilla bug 1955
Michele
5:58 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 08:55 AM, Slávek Banko wrote:
On Saturday 22 of February 2014 15:39:04 Michele
Calgaro wrote:
Slavek - I think I am almost done with the conversion. After spending 5 hours on
it, I can say with authority, by far, the the most costly miscalculation the TDE
project made was to take a *meat-cleaver* k->tde renaming approach, that has
resulted in wholesale renaming of k->tde and K->TDE to some classes,, headers
and functions and NOT others, instead of taking a surgical minimal renaming
approach to insure only conflicting executables, libraries and docbook language
were renamed.
You get into the code to migrate an application and there is NO rhyme or reason
to why some of the classes and headers are Kfoo or kfoo.h and why some have been
renamed TDEfoo or tdefoo.h. They are intermixed like scrambled eggs :(
I am on build 23 of kxmleditor after having:
# convert_existing_qt3_app_to_tqt3
# copy tde/common/admin
# sed -i 's/klocale.h/tdelocale.h/' *
# sed -i 's/klocale.h/tdelocale.h/' part/*.{cpp,h}
# sed -i 's/kmessagebox.h/tdemessagebox.h/' *
# sed -i 's/kmessagebox.h/tdemessagebox.h/' part/*.cpp
# sed -i 's/kapplication.h/tdeapplication.h/' kxmleditor/kxmleditor/main.cpp
# sed -i 's/kfiledialog.h/tdefiledialog.h/' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/kpopupmenu.h/tdepopupmenu.h/' kxmleditor/part/kxe_treeview.cpp
# sed -i 's/kpopupmenu.h/tdepopupmenu.h/' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/kglobal.h/tdeglobal.h/' kxmleditor/part/kxeconfiguration.cpp
# sed -i 's/KGlobal/TDEGlobal/' kxmleditor/part/kxe_treeview.cpp
# sed -i 's/KGlobal/TDEGlobal/' kxmleditor/part/kxeconfiguration.{h,cpp}
# sed -i 's/KConfig/TDEConfig/' kxmleditor/part/*.{cpp,h}
# sed -i 's/KConfig/TDEConfig/' kxmleditor/kxmleditor/kxmleditorshell.{cpp,h}
# sed -i 's/KIcon/TDEIcon/g' kxmleditor/part/kxeconfiguration.cpp
# sed -i 's/kconfig.h/tdeconfig.h/' kxmleditor/part/*.cpp
# sed -i 's/kfontcombo.h/tdefontcombo.h/' kxmleditor/part/*.{cpp,ui}
# sed -i 's/KFontCombo/TDEFontCombo/'
kxmleditor/part/kxeprintsettingspage.{h,cpp,ui}
# sed -i 's/klistview.h/tdelistview.h/' kxmleditor/part/kxe_treeviewitem.cpp
# sed -i 's/klistview.h/tdelistview.h/' kxmleditor/part/kxe_treeview.h
# sed -i 's/KListView/TDEListView/' kxmleditor/part/kxe_treeview.{cpp,h}
# sed -i 's/KListView/TDEListView/' kxmleditor/part/kxe_treeviewitem.{cpp,h}
# sed -i 's/kglobalsettings.h/tdeglobalsettings.h/'
kxmleditor/part/kxe_treeview.cpp
# sed -i 's/kaction.h/tdeaction.h/' kxmleditor/part/actions.h
# sed -i 's/kaction.h/tdeaction.h/' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/kaction.h/tdeaction.h/' kxmleditor/part/kxedocument.cpp
# sed -i 's/ktoolbar.h/tdetoolbar.h/' kxmleditor/part/actions.cpp
# sed -i 's/ktoolbar.h/tdetoolbar.h/' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/KAction/TDEAction/' kxmleditor/kxmleditor/kxmleditorshell.{h,cpp}
# sed -i 's/KToolBar/TDEToolBar/' kxmleditor/kxmleditor/kxmleditorshell.{h,cpp}
# sed -i 's/KAction/TDEAction/' kxmleditor/part/kxmleditorpart.{h,cpp}
# sed -i 's/KToolBar/TDEToolBar/' kxmleditor/part/kxmleditorpart.{h,cpp}
# sed -i 's/KAction/TDEAction/' kxmleditor/part/actions.cpp
# sed -i 's/KToolBar/TDEToolBar/' kxmleditor/part/actions.cpp
# sed -i 's/ktempfile.h/tdetempfile.h/g' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/ktempfile.h/tdetempfile.h/g' kxmleditor/part/kxedocument.cpp
# sed -i 's/KInstance/TDEInstance/' kxmleditor/part/kxmleditorfactory.{cpp,h}
# sed -i 's/KPopupMenu/TDEPopupMenu/'
kxmleditor/kxmleditor/kxmleditorshell.{cpp,h}
# sed -i 's/KPopupMenu/TDEPopupMenu/g' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/kaboutdata.h/tdeaboutdata.h/' kxmleditor/kxmleditor/main.cpp
# sed -i 's/kaboutdata.h/tdeaboutdata.h/' kxmleditor/part/kxmleditorabout.h
# sed -i 's/KAboutData/TDEAboutData/g' kxmleditor/part/kxmleditorabout.h
# sed -i 's/kfile.h/tdefile.h/' kxmleditor/part/kxedocument.cpp
I am still not done, but I'm getting close because it builds for several
minutes (about the time you would expect for an app this size) before crashing.
The point being it has taken some 5 hours of effort in the build, fail, what
failed, grep it, check /opt/trinity/include or /opt/tqt3/include to see if we
really are k or t, edit/sed, recreate tarball, rsync to build host, (repeat). If
there are ~130 modules in TDE many much, much larger than kxmleditor, that is
literally THOUSANDS of man hours put toward a ham-fisted renaming, when
something much smaller (or docbook only) may have been the smarter way to go...
--
David C. Rankin, J.D.,P.E.
Added to bugszilla bug 1955
Michele
Great, thank you.
Slavek
6:02 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
Le 22/02/2014 18:58, David C. Rankin a écrit :
On 02/22/2014 08:55 AM, Slávek Banko wrote:
You should use the "convert_existing_kde3_app_to_tde" script instead of
using your own sed command.
If you find the script is missing some renaming, you can report it here.
Francois
On Saturday 22 of February 2014 15:39:04 Michele
Calgaro wrote:
Slavek - I think I am almost done with the conversion. After spending 5 hours on
it, I can say with authority, by far, the the most costly miscalculation the TDE
project made was to take a *meat-cleaver* k->tde renaming approach, that has
resulted in wholesale renaming of k->tde and K->TDE to some classes,, headers
and functions and NOT others, instead of taking a surgical minimal renaming
approach to insure only conflicting executables, libraries and docbook language
were renamed.
You get into the code to migrate an application and there is NO rhyme or reason
to why some of the classes and headers are Kfoo or kfoo.h and why some have been
renamed TDEfoo or tdefoo.h. They are intermixed like scrambled eggs :(
I am on build 23 of kxmleditor after having:
# convert_existing_qt3_app_to_tqt3
# copy tde/common/admin
[...] Added to bugszilla bug 1955
Michele
Great, thank you.
Slavek
6:02 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Saturday 22 of February 2014 18:58:10 David C. Rankin wrote:
On 02/22/2014 08:55 AM, Slávek Banko wrote:
Oops, oops, what are you doing. You do not know script
experimental/kde-tde/convert_existing_kde3_app_to_tde?
Slavek
--
On Saturday 22 of February 2014 15:39:04 Michele
Calgaro wrote:
Slavek - I think I am almost done with the conversion. After spending 5
hours on it, I can say with authority, by far, the the most costly
miscalculation the TDE project made was to take a *meat-cleaver* k->tde
renaming approach, that has resulted in wholesale renaming of k->tde and
K->TDE to some classes,, headers and functions and NOT others, instead of
taking a surgical minimal renaming approach to insure only conflicting
executables, libraries and docbook language were renamed.
You get into the code to migrate an application and there is NO rhyme or
reason to why some of the classes and headers are Kfoo or kfoo.h and why
some have been renamed TDEfoo or tdefoo.h. They are intermixed like
scrambled eggs :(
I am on build 23 of kxmleditor after having:
# convert_existing_qt3_app_to_tqt3
# copy tde/common/admin
# sed -i 's/klocale.h/tdelocale.h/' *
# sed -i 's/klocale.h/tdelocale.h/' part/*.{cpp,h}
# sed -i 's/kmessagebox.h/tdemessagebox.h/' *
# sed -i 's/kmessagebox.h/tdemessagebox.h/' part/*.cpp
# sed -i 's/kapplication.h/tdeapplication.h/'
kxmleditor/kxmleditor/main.cpp # sed -i 's/kfiledialog.h/tdefiledialog.h/'
kxmleditor/part/kxmleditorpart.cpp # sed -i
's/kpopupmenu.h/tdepopupmenu.h/' kxmleditor/part/kxe_treeview.cpp # sed -i
's/kpopupmenu.h/tdepopupmenu.h/' kxmleditor/part/kxmleditorpart.cpp # sed
-i 's/kglobal.h/tdeglobal.h/' kxmleditor/part/kxeconfiguration.cpp # sed -i
's/KGlobal/TDEGlobal/' kxmleditor/part/kxe_treeview.cpp
# sed -i 's/KGlobal/TDEGlobal/' kxmleditor/part/kxeconfiguration.{h,cpp}
# sed -i 's/KConfig/TDEConfig/' kxmleditor/part/*.{cpp,h}
# sed -i 's/KConfig/TDEConfig/'
kxmleditor/kxmleditor/kxmleditorshell.{cpp,h} # sed -i 's/KIcon/TDEIcon/g'
kxmleditor/part/kxeconfiguration.cpp
# sed -i 's/kconfig.h/tdeconfig.h/' kxmleditor/part/*.cpp
# sed -i 's/kfontcombo.h/tdefontcombo.h/' kxmleditor/part/*.{cpp,ui}
# sed -i 's/KFontCombo/TDEFontCombo/'
kxmleditor/part/kxeprintsettingspage.{h,cpp,ui}
# sed -i 's/klistview.h/tdelistview.h/'
kxmleditor/part/kxe_treeviewitem.cpp # sed -i
's/klistview.h/tdelistview.h/' kxmleditor/part/kxe_treeview.h # sed -i
's/KListView/TDEListView/' kxmleditor/part/kxe_treeview.{cpp,h} # sed -i
's/KListView/TDEListView/' kxmleditor/part/kxe_treeviewitem.{cpp,h} # sed
-i 's/kglobalsettings.h/tdeglobalsettings.h/'
kxmleditor/part/kxe_treeview.cpp # sed -i 's/kaction.h/tdeaction.h/'
kxmleditor/part/actions.h
# sed -i 's/kaction.h/tdeaction.h/' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/kaction.h/tdeaction.h/' kxmleditor/part/kxedocument.cpp
# sed -i 's/ktoolbar.h/tdetoolbar.h/' kxmleditor/part/actions.cpp
# sed -i 's/ktoolbar.h/tdetoolbar.h/' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/KAction/TDEAction/'
kxmleditor/kxmleditor/kxmleditorshell.{h,cpp} # sed -i
's/KToolBar/TDEToolBar/' kxmleditor/kxmleditor/kxmleditorshell.{h,cpp} #
sed -i 's/KAction/TDEAction/' kxmleditor/part/kxmleditorpart.{h,cpp} # sed
-i 's/KToolBar/TDEToolBar/' kxmleditor/part/kxmleditorpart.{h,cpp} # sed -i
's/KAction/TDEAction/' kxmleditor/part/actions.cpp
# sed -i 's/KToolBar/TDEToolBar/' kxmleditor/part/actions.cpp
# sed -i 's/ktempfile.h/tdetempfile.h/g' kxmleditor/part/kxmleditorpart.cpp
# sed -i 's/ktempfile.h/tdetempfile.h/g' kxmleditor/part/kxedocument.cpp
# sed -i 's/KInstance/TDEInstance/'
kxmleditor/part/kxmleditorfactory.{cpp,h} # sed -i
's/KPopupMenu/TDEPopupMenu/' kxmleditor/kxmleditor/kxmleditorshell.{cpp,h}
# sed -i 's/KPopupMenu/TDEPopupMenu/g' kxmleditor/part/kxmleditorpart.cpp #
sed -i 's/kaboutdata.h/tdeaboutdata.h/' kxmleditor/kxmleditor/main.cpp #
sed -i 's/kaboutdata.h/tdeaboutdata.h/' kxmleditor/part/kxmleditorabout.h #
sed -i 's/KAboutData/TDEAboutData/g' kxmleditor/part/kxmleditorabout.h #
sed -i 's/kfile.h/tdefile.h/' kxmleditor/part/kxedocument.cpp
I am still not done, but I'm getting close because it builds for several
minutes (about the time you would expect for an app this size) before
crashing. The point being it has taken some 5 hours of effort in the build,
fail, what failed, grep it, check /opt/trinity/include or /opt/tqt3/include
to see if we really are k or t, edit/sed, recreate tarball, rsync to build
host, (repeat). If there are ~130 modules in TDE many much, much larger
than kxmleditor, that is literally THOUSANDS of man hours put toward a
ham-fisted renaming, when something much smaller (or docbook only) may have
been the smarter way to go... Added to bugszilla bug 1955
Michele
Great, thank you.
Slavek
6:10 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Saturday 22 of February 2014 19:02:31 Slávek Banko wrote:
Oops, oops, what are you doing. You do not know
script
experimental/kde-tde/convert_existing_kde3_app_to_tde?
A further two notes:
1) script convert_existing_qt3_app_to_tqt3 can perform some unwanted renaming.
The usual case is qui => tqui in some languages (french, spanish, ..). This
is necessary to treat.
2) Invidual steps of conversion I want push into GIT as individual commits. If
you want to prepare conversion of application, I need not result, but the
original source and invidual patches performing the conversion.
Slavek
--
6:45 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 12:10 PM, Slávek Banko wrote:
A further two notes:
1) script convert_existing_qt3_app_to_tqt3 can perform some unwanted renaming.
The usual case is qui => tqui in some languages (french, spanish, ..). This
is necessary to treat.
2) Invidual steps of conversion I want push into GIT as individual commits. If
you want to prepare conversion of application, I need not result, but the
original source and invidual patches performing the conversion.
Slavek
Grr... I guess I started with the wrong script :( I'll report back.
--
David C. Rankin, J.D.,P.E.
6:53 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 12:45 PM, David C. Rankin wrote:
On 02/22/2014 12:10 PM, Slávek Banko wrote:
Slavek, Francios,
I started over with:
# convert_existing_kde3_app_to_tde
# copy tde/common/admin
The build fails almost immediately. With convert_existing_qt3_app_to_tqt3 it
got much further. Do I also have to run convert_existing_qt3_app_to_tqt3?
Do you have a link to the conversion process howto? What are the steps?
--
David C. Rankin, J.D.,P.E.
A further two notes:
1) script convert_existing_qt3_app_to_tqt3 can perform some unwanted renaming.
The usual case is qui => tqui in some languages (french, spanish, ..). This
is necessary to treat.
2) Invidual steps of conversion I want push into GIT as individual commits. If
you want to prepare conversion of application, I need not result, but the
original source and invidual patches performing the conversion.
Slavek
Grr... I guess I started with the wrong script :( I'll report back.
7:18 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 12:53 PM, David C. Rankin wrote:
On 02/22/2014 12:45 PM, David C. Rankin wrote:
Slavek,
I will let you do it. Obviously I am missing something simple. Both the build
I did (the long way) and the build done by:
# ~/tde/tde/experimental/qt3-tqt3/convert_existing_qt3_app_to_tqt3
# ~/tde/tde/experimental/kde-tde/convert_existing_kde3_app_to_tde
# cp -r ~/tde/tde/main/common/admin .
Build for 1:12 seconds to what looks like the final linking steps and then
fail. It looks like it is really close, but there is a library missing from the
final link command - which one?? The error is:
libtool: link: g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2
-march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4
-fpermissive -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -Wl,-O1
-Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -o kxmleditor
dcopiface_shell.o kxmleditorshell.o main.o kxeshellmanager.o
dcopiface_shell_skel.o kxmleditorshell.moc.o -L/opt/trinity/lib -L/opt/tqt3/lib
-L/opt/trinity/lib/trinity /opt/trinity/lib/libtdeparts.so
/opt/trinity/lib/libtdeui.so /opt/trinity/lib/libtdecore.so
/opt/tqt3/lib/libtqt-mt.so -L/usr/lib/mysql -L/usr/X11R6/lib -luuid -lpq
-lmysqlclient -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype
-lfontconfig -ldl -lpng -lz -lm -lXext -lX11 -lSM -lICE /usr/lib/libtqt.so
-lpthread -Wl,-rpath -Wl,/opt/trinity/lib -Wl,-rpath -Wl,/opt/tqt3/lib
-Wl,-rpath -Wl,/opt/trinity/lib/trinity
/usr/bin/ld: kxmleditorshell.o: undefined reference to symbol
'_ZN11KFileDialog10getOpenURLERK8TQStringS2_P8TQWidgetS2_'
/opt/trinity/lib/libtdeio.so.14: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:629: recipe for target 'kxmleditor' failed
make[2]: *** [kxmleditor] Error 1
make[2]: Leaving directory '/build/tde-kxmleditor/src/kxmleditor/kxmleditor'
Makefile:575: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/build/tde-kxmleditor/src/kxmleditor'
Makefile:492: recipe for target 'all' failed
make: *** [all] Error 2
How to fix?
--
David C. Rankin, J.D.,P.E.
On 02/22/2014 12:10 PM, Slávek Banko wrote:
Slavek, Francios,
I started over with:
# convert_existing_kde3_app_to_tde
# copy tde/common/admin
The build fails almost immediately. With convert_existing_qt3_app_to_tqt3 it
got much further. Do I also have to run convert_existing_qt3_app_to_tqt3?
Do you have a link to the conversion process howto? What are the steps?
A further two notes:
1) script convert_existing_qt3_app_to_tqt3 can perform some unwanted renaming.
The usual case is qui => tqui in some languages (french, spanish, ..). This
is necessary to treat.
2) Invidual steps of conversion I want push into GIT as individual commits. If
you want to prepare conversion of application, I need not result, but the
original source and invidual patches performing the conversion.
Slavek
Grr... I guess I started with the wrong script :( I'll report back.
7:31 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
Le 22/02/2014 20:18, David C. Rankin a écrit :
Slavek,
I will let you do it. Obviously I am missing something simple. Both the build
I did (the long way) and the build done by:
# ~/tde/tde/experimental/qt3-tqt3/convert_existing_qt3_app_to_tqt3
# ~/tde/tde/experimental/kde-tde/convert_existing_kde3_app_to_tde
# cp -r ~/tde/tde/main/common/admin .
Build for 1:12 seconds to what looks like the final linking steps and then
fail. It looks like it is really close, but there is a library missing from the
final link command - which one?? The error is:
libtool: link: g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2
-march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4
-fpermissive -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -Wl,-O1
-Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -o kxmleditor
dcopiface_shell.o kxmleditorshell.o main.o kxeshellmanager.o
dcopiface_shell_skel.o kxmleditorshell.moc.o -L/opt/trinity/lib -L/opt/tqt3/lib
-L/opt/trinity/lib/trinity /opt/trinity/lib/libtdeparts.so
/opt/trinity/lib/libtdeui.so /opt/trinity/lib/libtdecore.so
/opt/tqt3/lib/libtqt-mt.so -L/usr/lib/mysql -L/usr/X11R6/lib -luuid -lpq
-lmysqlclient -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype
-lfontconfig -ldl -lpng -lz -lm -lXext -lX11 -lSM -lICE /usr/lib/libtqt.so
-lpthread -Wl,-rpath -Wl,/opt/trinity/lib -Wl,-rpath -Wl,/opt/tqt3/lib
-Wl,-rpath -Wl,/opt/trinity/lib/trinity
/usr/bin/ld: kxmleditorshell.o: undefined reference to symbol
'_ZN11KFileDialog10getOpenURLERK8TQStringS2_P8TQWidgetS2_'
/opt/trinity/lib/libtdeio.so.14: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:629: recipe for target 'kxmleditor' failed
make[2]: *** [kxmleditor] Error 1
make[2]: Leaving directory '/build/tde-kxmleditor/src/kxmleditor/kxmleditor'
Makefile:575: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/build/tde-kxmleditor/src/kxmleditor'
Makefile:492: recipe for target 'all' failed
make: *** [all] Error 2
How to fix?
It's really common with these old programes that there are missing
linker flags in the Makefile.
It looks like nowaday's compiler are much stricter, we must specify
every library to link, there is no auto-detection at all.
On some distribution (like Mageia :-) ) the error message that I get
from the linker tells exactly what library is required, whereas yours
only shows the missing symbol, which is not really helpful.
I'll try to build this tool and see what is wrong here.
Francois
7:46 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 01:31 PM, François Andriot wrote:
It's really common with these old programes that
there are missing linker flags
in the Makefile.
It looks like nowaday's compiler are much stricter, we must specify every
library to link, there is no auto-detection at all.
On some distribution (like Mageia :-) ) the error message that I get from the
linker tells exactly what library is required, whereas yours only shows the
missing symbol, which is not really helpful.
I'll try to build this tool and see what is wrong here.
Francois
Thank you Francios!
--
David C. Rankin, J.D.,P.E.
8:13 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
Le 22/02/2014 20:46, David C. Rankin a écrit :
On 02/22/2014 01:31 PM, François Andriot wrote:
Bug report 1955 updated.
It's really common with these old programes
that there are missing linker flags
in the Makefile.
It looks like nowaday's compiler are much stricter, we must specify every
library to link, there is no auto-detection at all.
On some distribution (like Mageia :-) ) the error message that I get from the
linker tells exactly what library is required, whereas yours only shows the
missing symbol, which is not really helpful.
I'll try to build this tool and see what is wrong here.
Francois
Thank you Francios!
8:39 p.m.
New subject: SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 02:13 PM, François Andriot wrote:
Le 22/02/2014 20:46, David C. Rankin a écrit :
These are the changes that allowed kxmleditor to build:
# ~/tde/tde/experimental/qt3-tqt3/convert_existing_qt3_app_to_tqt3
# ~/tde/tde/experimental/kde-tde/convert_existing_kde3_app_to_tde
# cp -r ~/tde/tde/main/common/admin .
# sed -i 's/LIB_KFILE/LIB_TDEFILE/' kxmleditor/kxmleditor/Makefile.am
# sed -i 's/LIB_KFILE/LIB_TDEFILE/' kxmleditor/part/Makefile.am
# sed -i 's/LIB_KFILE/LIB_TDEFILE/' kxmleditor/part/Makefile.in
# kxmleditor/Makefile.am: kxmleditor_LDFLAGS = $(all_libraries) $(KDE_RPATH)
$(LIB_QT) -lDCOP $(LIB_TDECORE) $(LIB_TDEUI) -ltdefx
Basically, I copied the libraries from kdiff3. I think the only one that was
missing was -lDCOP. I'm just glad it builds. I'll test Francios patch too.
I have the diff if you want it, but just following the steps above work.
--
David C. Rankin, J.D.,P.E.
On 02/22/2014 01:31 PM, François Andriot wrote:
Bug report 1955 updated.
It's really common with these old programes
that there are missing linker flags
in the Makefile.
It looks like nowaday's compiler are much stricter, we must specify every
library to link, there is no auto-detection at all.
On some distribution (like Mageia :-) ) the error message that I get from the
linker tells exactly what library is required, whereas yours only shows the
missing symbol, which is not really helpful.
I'll try to build this tool and see what is wrong here.
Francois
Thank you Francios!
8:53 p.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 02:39 PM, David C. Rankin wrote:
On 02/22/2014 02:13 PM, François Andriot wrote:
Updated bug 1955:
Works Great!
http://www.3111skyline.com/dl/dt/trinity/ss/kxmleditor.jpg
When you push the source to the git-tree, we will need to update the kmenu
location. It currently installs to:
kmenu/Utilities/KDE3/Editors
we need to patch it to install at
kmenu/Utilities/Editors
We should also move or duplicate
kmenu/Utilities/File/kHexEdit
in
kmenu/Utilities/Editors.
That way ALL of the editors (text, hex and xml) are all available under
Editors.
--
David C. Rankin, J.D.,P.E.
Le 22/02/2014 20:46, David C. Rankin a écrit :
These are the changes that allowed kxmleditor to build:
# ~/tde/tde/experimental/qt3-tqt3/convert_existing_qt3_app_to_tqt3
# ~/tde/tde/experimental/kde-tde/convert_existing_kde3_app_to_tde
# cp -r ~/tde/tde/main/common/admin .
# sed -i 's/LIB_KFILE/LIB_TDEFILE/' kxmleditor/kxmleditor/Makefile.am
# sed -i 's/LIB_KFILE/LIB_TDEFILE/' kxmleditor/part/Makefile.am
# sed -i 's/LIB_KFILE/LIB_TDEFILE/' kxmleditor/part/Makefile.in
# kxmleditor/Makefile.am: kxmleditor_LDFLAGS = $(all_libraries) $(KDE_RPATH)
$(LIB_QT) -lDCOP $(LIB_TDECORE) $(LIB_TDEUI) -ltdefx
Basically, I copied the libraries from kdiff3. I think the only one that was
missing was -lDCOP. I'm just glad it builds. I'll test Francios patch too.
I have the diff if you want it, but just following the steps above work.
On 02/22/2014 01:31 PM, François Andriot wrote:
Bug report 1955 updated.
It's really common with these old programes
that there are missing linker flags
in the Makefile.
It looks like nowaday's compiler are much stricter, we must specify every
library to link, there is no auto-detection at all.
On some distribution (like Mageia :-) ) the error message that I get from the
linker tells exactly what library is required, whereas yours only shows the
missing symbol, which is not really helpful.
I'll try to build this tool and see what is wrong here.
Francois
Thank you Francios!
10:54 p.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
we need to patch it to install at
kmenu/Utilities/Editors
Who is going to use an XML editor? Mom and pop? Never. I prefer placing the new app in
Development->Web Development, next to Quanta Plus.
We should also move or duplicate
kmenu/Utilities/File/kHexEdit
in
kmenu/Utilities/Editors.
Leave khexedit at the current location: Utilities->File.
I'll fight menu duplication all the way to Hell. I've been down this road before.
When menus are populated to the point that they need to roll-over to a second or third
column to show all menu items then the menu is cluttered beyond usability. Especially true
on small screens such as laptops, netbooks, and tablets. Add KDE menu items to a Trinity
menu and the clutter begins. Even with the "[KDE]" suffix or pushing all KDE
apps into their own sub menu still creates clutter.
One of the big challenges of usability design these days is too many developers using
monitors that are bigger than televisions and then not testing on small displays. Same
problem with all the idiotic web developers who never test their damn small fonts on small
monitors. Oh, looks great on my jumbotron.
That way ALL of the editors (text, hex and xml) are
all available under
Editors.
Not all editors are "editors" as most people use the word. I doubt much that
most users have even heard of a hex editor, let alone look for one. Likewise for an XML
editor. Stop thinking like a geek.
--
Darrell
11:12 p.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 04:54 PM, Darrell wrote:
Why would you leave kHexEdit in 'Files'? Yes, all editors edit 'Files',
but
'Files' is normally for tools that move, copy, rename, compress, decompress,
etc.. Files. I had to use the kmenu search: [ ] to find the darn thing.
I don't want duplication either, I just know if I can't find things in the menu,
then there are going to be others in the same boat. Like I say below, I don't
care where it goes, if you are setting them menu, then put it where you like, I
think people normally look for things that edit files under 'Editor'.
I've been down this road
Who is going to use an XML editor? Mom and pop? Never.
I prefer placing the
new app in Development->Web Development, next to Quanta Plus.
I use it all the time. Hundreds of your data files in TDE are xml, all your wiki
templates and a bulk of your web content you run into are in xml.
> We should
also move or duplicate kmenu/Utilities/File/kHexEdit in
> kmenu/Utilities/Editors.
Leave khexedit at the current location:
Utilities->File.
I'll fight menu duplication all the way to Hell. before. When menus are populated to the point that
they need to roll-over to
a second or third column to show all menu items then the menu is cluttered
beyond usability. Especially true on small screens such as laptops, netbooks,
and tablets. Add KDE menu items to a Trinity menu and the clutter begins.
Even with the "[KDE]" suffix or pushing all KDE apps into their own sub menu
still creates clutter.
One of the big challenges of usability design these days is too many
developers using monitors that are bigger than televisions and then not
testing on small displays. Same problem with all the idiotic web developers
who never test their damn small fonts on small monitors. Oh, looks great on
my jumbotron.
I'm tired too. I don't care where it goes, but scattering editors all over the
menu tree just seems like a bad idea. If it wasn't for the Search: [ ] in
kmenu, I couldn't find things half the time and would just use Alt+F2. I know I
wasn't here when kmenu got moved around, so I'll live with where things are.
This stuff is so easy to change, if there are better ideas of where things
should go, I think we should all be open to considering them.
--
David C. Rankin, J.D.,P.E.
> That way ALL of the editors (text, hex and
xml) are all available under
> Editors.
Not all editors are "editors" as most people use the word.
I doubt much that
most users have even heard of a hex editor, let alone look for one. Likewise
for an XML editor. Stop thinking like a geek.
11:30 p.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Sat February 22 2014 5:12:48 pm David C. Rankin wrote:
On 02/22/2014 04:54 PM, Darrell wrote:
> Who is going to use an XML editor? Mom and pop? Never. I prefer placing the
> new app in Development->Web Development, next to Quanta Plus.
Right. You are a geek (as am I). Mom and pop are not. Don't clutter and confuse their
perspective. Geeks find things. Moms and pops don't. Throwing non text editors into
the Editors sub menu confuses such people.
Why would you leave kHexEdit in 'Files'? Yes,
all editors edit 'Files', but
'Files' is normally for tools that move, copy, rename, compress, decompress,
etc.. Files. I had to use the kmenu search: [ ] to find the darn thing.
Because in both a geek world and non-geek world I don't ever think of a hex editor as
a traditional editor. I use the word "editor" in reference to editing text. Yes,
I've been using computers since the 1970s and I am aware that the word
"editor" can and is broadly used.
Among geeks.
Whenever I want to use a hex editor, which is seldom. I am not looking for a text editor
in the traditional sense. I don't look in the Editors sub menu.
As a tech writer I have found that most of the writers I have worked with are not geeks,
despite their dependence upon computers. Most I would label (firmly) as computer
illiterate. They learn only what they need to know. This is my observation of all people
using computers. Only geeks go further.
And yes, I have been asked, "What is a hex editor?"
That is just the English side. Many of these words do not translate well into other
languages.
Even in the English side words do not always translate as expected. Years ago when I
visited New Zealand I was warned not to ask for a napkin when in a restaurant. Instead ask
for a serviette. Why? Because in New Zealand a napkin is short-hand for feminine napkin.
I'm tired too. I don't care where it goes, but
scattering editors all over the
menu tree just seems like a bad idea. If it wasn't for the Search: [ ] in
kmenu, I couldn't find things half the time and would just use Alt+F2. I know I
wasn't here when kmenu got moved around, so I'll live with where things are.
This stuff is so easy to change, if there are better ideas of where things
should go, I think we should all be open to considering them.
You define all of these apps at "editors" rather than as "tools."
Speaking of the Search field, many users refuse to look even for the basic apps they use
every day. I have seen this often working with other people. Their solution? They slap a
shortcut on the desktop to avoid using the menu.
The result? After a few months the desktop is cluttered with shortcut icons and they
cannot find what they seek.
Do they learn? No. The next time they use a new app they create Yet Another Shortcut.
For myself I rarely use the Search field. When I do, and that happens only on my test
machine with all of the additional apps, I then realize I am suffering from menu clutter
and app overload.
--
Darrell
23 Feb
23 Feb
12:17 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Sat February 22 2014 5:12:48 pm David C. Rankin wrote:
On 02/22/2014 04:54 PM, Darrell wrote:
I am curious. What about quanta plus? Various kate plugins. Why a new app?
--
Darrell
Who is going to use an XML editor? Mom and pop?
Never. I prefer placing the
new app in Development->Web Development, next to Quanta Plus.
I use it all the time. Hundreds of your data files in TDE are xml, all your wiki
templates and a bulk of your web content you run into are in xml.
4:47 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 06:17 PM, Darrell wrote:
On Sat February 22 2014 5:12:48 pm David C. Rankin
wrote:
Quanta+ is OK, but it all it does is provide xsl,xml validation, but it is a
text editor, not an xml editor. Yes, I use a text editor at times to edit xml,
but you have to be very particular that you do not screw up any of the
hierarchical structure or you break the file, for short files with few subtags,
that isn't an issue, but on a large file, that is easier said than done.
xmleditor - is just that, an xml editor. It preserves the xml schema of the
document (protecting it from accidents) and gives you access to the xml 'data'.
That is what makes it superior to a text editor.
--
David C. Rankin, J.D.,P.E.
On 02/22/2014 04:54 PM, Darrell wrote:
I am curious. What about quanta plus? Various kate plugins. Why a new app?
Who is going to use an XML editor? Mom and pop?
Never. I prefer placing the
new app in Development->Web Development, next to Quanta Plus.
I use it all the time. Hundreds of your data files in TDE are xml, all your wiki
templates and a bulk of your web content you run into are in xml.
22 Feb
22 Feb
11:12 p.m.
New subject: New package check list
When you push the source to the git-tree, we will need
to update the kmenu
location. It currently installs to:
I don't mind adding new packages. I have a long list of candidates I'll post.
Yet when adding new packages I urge using a check list to ensure the new package meets
current Trinity standards and not the shoddy standards of kde-look.org and sourceforge.net
KDE3 packages.
Basically, I busted my ass the past month fixing a horribly broken and embarrassing help
handbook system. I am not about to let that hard work disintegrate every time we add a new
app.
Here is a starter check list. I derived this check list from my recent work with the help
handbooks, which exposed a lot of crappy and lazy work by the original developers as well
as other bugs.
New package addition check list:
1. Create a bug report (enhancement request) for any new candidate package.
That way anything listed below that can not be resolved has a place holder.
Do not proceed past this step unless a bug report is opened.
2. Convert as necessary to current TQt3 requirements.
This process needs to be openly documented to encourage other people to perform some of
the work.
3. Verify the package builds on at least three different distros.
Typically Debian-based, RPM-based, and then an independent such as Arch or Slackware.
4. Verify a help handbook exists.
* If none exists, then add a "We Apologize" shell handbook.
* Verify the shell handbook template is updated to reference the new app.
5. For existing help handbooks, review the header information:
* Update the DocType declaration.
* Update internal entities (for example, &kde;->&tde;).
* Do not add internal entities to general.entities (tdelibs).
* Add copyright information for &tde-team;.
* Add author information for &tde-authors;.
* Update release date.
* Update version.
* Remove versions from handbook title information.
* Ensure all header information satisfies current layout standards.
6. Verify the help handbook opens when selecting the handbook from the Help menu.
7. When secondary help handbooks are included, verify the additional handbook is available
in the Help menu.
Look at the kate Help menu as an example (kate plugins handbook).
* Verify the additional help handbook populates the help handbook table of contents.
8. Verify a Help button is available in the configuration dialogs.
9. For certain configuration Help buttons, verify the help handbook opens to the correct
handbook section rather than the top of the handbook.
* Create additional *.desktop files to support opening to specific handbook sections.
10. Review existing *.desktop files:
* Categories key must satisfy existing launcher menu structure.
* The app populates only one launcher menu category.
* Superfluous menu options are silenced in the launcher menu (such as kbarcode).
* The Icon key references an icon that actually exists.
* The icon appears in the launcher menu.
* The icon appears the help handbook table of contents.
* The DocPath key references the correct location of the help handbook
The correct location is index.html and not appname.html.
* Both a Name and GenericName key are defined to satisfy Description/Name and
Name/Description menu users.
* Verify Trinity supports new or obscure mimetypes specified.
11. Verify i18n files are reviewed or added.
This is a draft check list.
--
Darrell
11:21 p.m.
New subject: [trinity-devel] Re: New package check list
On 02/22/2014 05:12 PM, Darrell wrote:
That is a good checklist. kxmledit is a package that is is very good shape. It's
khelpcenter files integrate perfectly with TDE, you have no additional work to
do. Take a look:
http://www.3111skyline.com/dl/dt/trinity/ss/kxmleditor-khelp.jpg
--
David C. Rankin, J.D.,P.E.
When you push
the source to the git-tree, we will need to update the kmenu
location. It currently installs to:
I don't mind adding new packages. I have a long list of candidates I'll post.
Yet when adding new packages I urge using a check list to ensure the new package meets
current Trinity standards and not the shoddy standards of kde-look.org and sourceforge.net
KDE3 packages.
Basically, I busted my ass the past month fixing a horribly broken and embarrassing help
handbook system. I am not about to let that hard work disintegrate every time we add a new
app.
Here is a starter check list. I derived this check list from my recent work with the help
handbooks, which exposed a lot of crappy and lazy work by the original developers as well
as other bugs.
New package addition check list:
1. Create a bug report (enhancement request) for any new candidate package.
That way anything listed below that can not be resolved has a place holder.
Do not proceed past this step unless a bug report is opened.
2. Convert as necessary to current TQt3 requirements.
This process needs to be openly documented to encourage other people to perform some
of the work.
3. Verify the package builds on at least three different distros.
Typically Debian-based, RPM-based, and then an independent such as Arch or Slackware.
4. Verify a help handbook exists.
* If none exists, then add a "We Apologize" shell handbook.
* Verify the shell handbook template is updated to reference the new app.
5. For existing help handbooks, review the header information:
* Update the DocType declaration.
* Update internal entities (for example, &kde;->&tde;).
* Do not add internal entities to general.entities (tdelibs).
* Add copyright information for &tde-team;.
* Add author information for &tde-authors;.
* Update release date.
* Update version.
* Remove versions from handbook title information.
* Ensure all header information satisfies current layout standards.
6. Verify the help handbook opens when selecting the handbook from the Help menu.
7. When secondary help handbooks are included, verify the additional handbook is
available in the Help menu.
Look at the kate Help menu as an example (kate plugins handbook).
* Verify the additional help handbook populates the help handbook table of contents.
8. Verify a Help button is available in the configuration dialogs.
9. For certain configuration Help buttons, verify the help handbook opens to the correct
handbook section rather than the top of the handbook.
* Create additional *.desktop files to support opening to specific handbook sections.
10. Review existing *.desktop files:
* Categories key must satisfy existing launcher menu structure.
* The app populates only one launcher menu category.
* Superfluous menu options are silenced in the launcher menu (such as kbarcode).
* The Icon key references an icon that actually exists.
* The icon appears in the launcher menu.
* The icon appears the help handbook table of contents.
* The DocPath key references the correct location of the help handbook
The correct location is index.html and not appname.html.
* Both a Name and GenericName key are defined to satisfy Description/Name and
Name/Description menu users.
* Verify Trinity supports new or obscure mimetypes specified.
11. Verify i18n files are reviewed or added.
This is a draft check list.
11:37 p.m.
New subject: [trinity-devel] Re: New package check list
That is a good checklist. kxmledit is a package that
is is very good shape. It's
khelpcenter files integrate perfectly with TDE, you have no additional work to
do. Take a look:
http://www.3111skyline.com/dl/dt/trinity/ss/kxmleditor-khelp.jpg
Interesting picture. The fact that the alleged help file opens means little.
So now add another item to the check list:
* The app supports a standard help handbook docbook format (not a
I-am-a-lazy-ass-developer html file).
These lazy-ass html files do not satisfy any of the help handbook criteria. There is no
docbook file.
krename and kdbg fall into this same category.
Somebody with some serious scripting savvy could help by creating a conversion script. I
have search the web and nobody has anything of quality to convert html to docbook.
--
Darrell
23 Feb
23 Feb
10:28 a.m.
New subject: [trinity-devel] Re: New package check list
On 02/22/2014 05:37 PM, Darrell wrote:
Interesting picture. The fact that the alleged help
file opens means little.
So now add another item to the check list:
* The app supports a standard help handbook docbook format (not a
I-am-a-lazy-ass-developer html file).
These lazy-ass html files do not satisfy any of the help handbook criteria.
There is no docbook file.
krename and kdbg fall into this same category.
Somebody with some serious scripting savvy could help by creating a
conversion script. I have search the web and nobody has anything of quality
to convert html to docbook.
There are some distinct advantages to html over docbook, especially for any
large help files. I much prefer being able to scroll up/down and quickly find
the information I need rather than trying to click Next/Back/Up/Home trying to
hop around getting from point A to B in docbook.
Now docbook indexing is an advantage over HTML, but HTML provides a distinct
advantage in usability.
Testing kxmleditor, I select Help from the Help menu and a very clean and
complete help document appeared. The average user doesn't care what format the
underlying information is contained in, they just want good and useful help when
they press [Help].
As for as a conversion script goes, it shouldn't be that hard to develop. I'll
look at it when I get systemd done. I say the docbook standards in the admin or
one of the other guides in the past day or so.
Honestly, providing both wouldn't be a bad idea, especially for the longer
manuals if that is possible. I don't know if they conflict with each other, but
I found myself earlier using meinproc to change the administrative-guide back to
html for just these reasons. It is almost impossible to hop back and forth
effectively in docbook, but it is simple to grab the scrollbar on the window and
move from the top to bottom, or any point in between, with the html file.
I think for all all core-tde modules, docbook is a 'must have', but for all the
non-core modules it becomes much more of a 'nice to have' as long as good help
is available when you press F1.
--
David C. Rankin, J.D.,P.E.
4:53 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
That way ALL of the editors (text, hex and xml) are
all available under
Editors.
Speaking of editors, I am surprised we never ported the last Qt3 version of Scribus.
Somewhere around the 1.3.3 versions. They were using cmake by then too.
--
Darrell
5:09 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Sat February 22 2014 10:53:48 pm Darrell wrote:
Looks like 1.3.3.14 was Qt3.
Version 1.3.5 was the first Qt4 version.
--
Darrell
That way ALL
of the editors (text, hex and xml) are all available under
Editors.
Speaking of editors, I am surprised we never ported the last Qt3 version of Scribus.
Somewhere around the 1.3.3 versions. They were using cmake by then too.
7:07 a.m.
New subject: R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
Actually a good XML editor is a very useful tool and something that TDE has been lacking
so far. KXMLEditor will fill that void.
I favor David's suggestion. If I am looking for an editor I either look in
"Editor" or "Development", but definitely it wouldn't come natural
to look into "File". If I can't the editor there, then I use the "menu
search" field to locate where the editor was installed.
Having all general editors (text, hex and XML) in the same menu (utilities -> editor)
is a reasonable idea and given that the number of editors is not that big, I don't see
the "editor" menu becoming over busy.
Other people opinions are welcomed too, since it seems there is a little of disagreement
on this matter.
Cheers
Michele
12:28 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Sun, 23 Feb 2014 07:07:38 +0000 (GMT)
Michele Calgaro <michele.calgaro(a)yahoo.it> wrote:
Actually a good XML editor is a very useful tool and
something that TDE has been lacking so far. KXMLEditor will fill that void.
I favor David's suggestion. If I am looking for an editor I either look in
"Editor" or "Development", but definitely it wouldn't come
natural to look into "File". If I can't the editor there, then I use the
"menu search" field to locate where the editor was installed.
Having all general editors (text, hex and XML) in the same menu (utilities -> editor)
is a reasonable idea and given that the number
of editors is not that big, I don't see the "editor" menu becoming over
busy.
Other people opinions are welcomed too, since it seems there is a little of disagreement
on this matter.
I think Development, rather than Editors, is likely the most appropriate place.
IMHO, Darrell is right about things like KHexEdit confusing non-technical
users (who may also not grasp how to rearrange the menu), but File is also
a rather odd location. Also, if we throw that menu subsection open to
non-text editors, it starts to sound like it should also be the place for the
menu editor and image editors and video editors and . . . well, really,
where does it end?
Development, on the other hand, is one of the locations a technical person
will look in first for that sort of software, and a non-technical person will
probably ignore that submenu altogether.
Part of the problem is that "utilities" seems to have historically been used
as a bit of a dumping ground category. It might benefit from a close
re-examination of exactly what's been filed there. I just don't know if
now is the best time to do it.
With respect to the menu structure in general, we have three forces
pulling in different directions: the desire to keep the menu logically
arranged (where not everyone agrees on what's logical), the desire not
to overload any given menu, and the historical structure of the packages.
KHexEdit is exactly the type of application most likely to end up getting
used as a rope in that tug-of-war. I'm less worried about KXMLEditor,
because it isn't part of a core package and isn't likely to be installed by
people who don't know what it's for.
As for Scribus--before we get too carried away, make sure that the last
QT3 version had fixed that weird bug where the mouse cursor and text in
the main work area didn't share the same positioning data. That used to
make it almost unusable.
E. Liddell
1:49 p.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Sunday 23 of February 2014 13:32:12 Michele Calgaro wrote:
Development sounds like a good place.
--
Slavek
I think
Development, rather than Editors, is likely the most appropriate
place.
I am fine with Development, for both KHexEdit and KXMLEditor. Sounds quite
logical. Michele
25 Feb
25 Feb
3:24 a.m.
New subject: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/23/2014 06:32 AM, Michele Calgaro wrote:
Development is find for both. All text editors in Editors, all non-text/xml
editors in Development works.
--
David C. Rankin, J.D.,P.E.
I think
Development, rather than Editors, is likely the most appropriate place.
I am fine
with Development, for both KHexEdit and KXMLEditor. Sounds quite logical.
Michele
23 Feb
23 Feb
8:47 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/22/2014 10:53 PM, Darrell wrote:
I would also vote for Scribus. I think it is an indispensable. Desktop
publishing is a thing in and of itself, you can't fake true dtp with a word
processor. Looking at what is available, it looks like we will have to use:
scribus-1.3.3.14
http://downloads.sourceforge.net/project/scribus/scribus/1.3.3.14/scribus-1…
It appears to be the last in the line of Qt3 releases and was the 16th release
of Scribus 1.3.x. It should be fairly stable.
The current version 1.4.3 is a Qt4 based packaged - "don't throw me in that
briarpatch..." It would take conversion, but it would be a quality addition to TDE.
--
David C. Rankin, J.D.,P.E.
That way ALL
of the editors (text, hex and xml) are all available under
Editors.
Speaking of editors, I am surprised we never ported the last Qt3 version of
Scribus. Somewhere around the 1.3.3 versions. They were using cmake by then
too.
11:33 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
Scribus:
open bug report 1857.
David, when you want a program to be added to the repo, just file a bug report for it,
it's the best way to "don't forget it".
Michele
5:37 p.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Sun February 23 2014 5:33:17 am Michele Calgaro wrote:
Scribus:
open bug report 1857.
(1957). If you folks want additional apps, I have a long list of KDE3 apps that could be
added. I still have access to the sources and Slackware build scripts.
A challenge is many of these apps are useless and were useless when they were first
introduced. Many now are useless because of obsolete dependencies, such as HAL and esound,
or obsolete online URLs.
Then there are the usual problems discussed previously with help handbooks, incomplete
*.desktop files, missing Help buttons, etc. There is a reason most of these apps never
merged upstream into KDE: poor quality.
A bigger challenge with adding apps is we keep spreading ourselves thinner and thinner. At
this moment the bug report backlog looks like this:
Blocker: 5
Critical: 7
Regressions: 18
Help Handbook: 20
PATCHAVAIL: 33
stdout/stderr: 49
Basically these bug reports are ignored. "Not my itch" is a common theme in this
project. Additional apps will not change anything. Who will support these new apps?
I would like to see us devote a few weeks to eliminating all of the above. Everybody would
agree to stop scratching their own itches and would agree to help eliminate the above
backlog.
David, when you want a program to be added to the
repo, just file a bug report for it, it's the best way to "don't forget
it".
The dev mail list stopped being a useful place to resolve bugs. That hasn't happened
in about 18 months. Just file bug reports. Posting bugs to the list is like spitting into
the wind.
--
Darrell
24 Feb
24 Feb
6:55 a.m.
New subject: Is is time for R14.0.0-alpha (which is intended as "before RC1")?
I would like to see us devote a few weeks to
eliminating all of the above. Everybody would agree to stop scratching
their own itches and would agree to help eliminate the above backlog.
That would be a good thing to do, if we really want to get R14 out of the door
"soon".
I don't mind new bug reports and new apps, but if we don't focus on the existing
open points, we can easily find ourselves in August still discussing whether it is time
for RC1 or not :-(
When R14 is ready, we can look at integrating more apps, enhance the handbooks (Darrell
has been doing a great job but there is simply too much to do and this will extend far
beyond R14.0.0), general improvements and so on.
Actually, during the weekend I was considering the question "should we create a
branch R14.0.0-alpha" ? The reason for that is to establish a "base" to
work on for moving towards R14 release, with an eye in preventing new bugs to enter
R14.0.0 code.
Until now whatever comes along goes into the trunk. This can easily introduce new bugs
(for example see bug 1857 introduced in Dec 22, 2013). I am worry that the next fix for
problem ABC will introduce new regression bugs for apps DEF and GHJ and so on...
Even though we are not ready for RC1, I feel the need for some kind of
"milestone" to base our future work.
R14.0.0-alpha would be the first of such milestones. Then we make a list of bugs that need
to be fixed for R14.0.0 and start working on those.
Whatever else (fixes, new developments) comes along would go into the trunk but not in the
R14.0.0 branch, unless it is a proven problem for R14 users (ex. critical bugs,
instabilities, major lack of functionalities...).
In this way we will be able to get closer to a release date at a steady pace, without the
risk of a new commit introducing bugs that would require two more months for new fixes and
so on... (which is more or less what has been going on in 2013 :) )
Sometimes along the way, we will have a R14.0.0-beta and when most of the items have been
worked on, we can discuss RC1.
Opinions are welcome as usual.
Cheers
Michele
PS: if we mark "R14.0.0-alpha", we can also add that as a news on TDE website,
which is a good thing as well.
7:29 a.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
On Mon February 24 2014 12:55:02 am Michele Calgaro wrote:
Actually, during the weekend I was considering the
question "should we create a branch R14.0.0-alpha" ? The reason for that is to
establish a "base" to work on for moving towards R14 release, with an eye in
preventing new bugs to enter R14.0.0 code.
I support that idea. I will have to create an R14-alpha partition or VM, but that is
doable.
We would have to work on backporting patches from the main trunk when they apply to
directly R14-alpha (almost exclusively bug fixes only), but we've been through this
before with 3.5.13.2. Conversely, any patch directly applicable to R14-alpha gets
concurrently merged into trunk.
Fortunately, there will be no renaming patches backported that we have to reverse before
merging into R14-alpha. All renaming patches stay in main trunk.
Two branches will help us focus on not introducing new bugs into R14.0.0. Frankly, I'm
getting pretty beat up with all the bug reports I keep filing. I don't mind filing the
reports, but we need to get our heads back above the water with respect to R14.0.0.
When ready we simply declare the R14-alpha branch to be the R14-RC1 branch, then RC2,
etc.
--
Darrell
8:16 a.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
On Monday 24 of February 2014 08:29:40 Darrell wrote:
On Mon February 24 2014 12:55:02 am Michele Calgaro
wrote:
I have nothing against establishing a new branch.
But I'm not sure that now is the right time.
We want to establish a new branch in order to integrate new applications? We
want to establish a new branch in order to "do new things"? On both I say
unambiguous: not now. We need to devote all effort to pushing R14.0.0 out the
door. We are too few of us to split our efforts. If we now begin to address
new applications or new things, it will have a negative consequence on time
to release R14.0.0.
I suggest at this point to completely stop the debate on new applications and
pursue exclusively the tasks necessary for R14.0.0. Let them be filled bug
reports for new applications and we will pursue them after the release
R14.0.0. Keep in mind that our team is small, and that for us was a great
luxury to divide our efforts at this time.
--
Slavek
Actually, during the weekend I was considering
the question "should we
create a branch R14.0.0-alpha" ? The reason for that is to establish a
"base" to work on for moving towards R14 release, with an eye in
preventing new bugs to enter R14.0.0 code.
I support that idea. I will have to create an R14-alpha partition or VM,
but that is doable.
We would have to work on backporting patches from the main trunk when they
apply to directly R14-alpha (almost exclusively bug fixes only), but we've
been through this before with 3.5.13.2. Conversely, any patch directly
applicable to R14-alpha gets concurrently merged into trunk.
Fortunately, there will be no renaming patches backported that we have to
reverse before merging into R14-alpha. All renaming patches stay in main
trunk.
Two branches will help us focus on not introducing new bugs into R14.0.0.
Frankly, I'm getting pretty beat up with all the bug reports I keep filing.
I don't mind filing the reports, but we need to get our heads back above
the water with respect to R14.0.0.
When ready we simply declare the R14-alpha branch to be the R14-RC1 branch,
then RC2, etc.
8:34 a.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
I have nothing against establishing a new branch.
But I'm not sure that now is the right time.
We want to establish a new branch in order to integrate new applications? We
want to establish a new branch in order to "do new things"? On both I say
unambiguous: not now. We need to devote all effort to pushing R14.0.0 out the
door. We are too few of us to split our efforts. If we now begin to address
new applications or new things, it will have a negative consequence on time
to release R14.0.0.
I understood the branch suggestion to mean a way to separate aggressive hacking from
R14.0.0 hacking.
I suggest at this point to completely stop the debate
on new applications and
pursue exclusively the tasks necessary for R14.0.0. Let them be filled bug
reports for new applications and we will pursue them after the release
R14.0.0. Keep in mind that our team is small, and that for us was a great
luxury to divide our efforts at this time.
Sure, that is good. If we keep using the main trunk as the place to push R14.0.0 related
patches, then we should all agree not to push anything esoteric or new. Bug fixes and
nominal feature tweaks only. At one time we were at feature freeze but that got lost soon
thereafter. Perhaps we should again declare a feature freeze, which then would satisfy
Michele's suggestion. But if we go into feature freeze then all of us should focus on
R14.0.0 and nothing else. If we again declare feature freeze then that becomes R14-alpha.
--
Darrell
9:59 a.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
Slavek, Darrell,
all three of us are saying the same thing: let's focus on the tasks needed to release
R14.0.0
Highlighting both of your comments:
> I suggest at this point to completely stop the
debate on new applications and
> pursue exclusively the tasks necessary for R14.0.0.
At one time we were at feature freeze but that got
lost soon thereafter.
Perhaps we should again declare a feature freeze: all of us should focus on R14.0.0 and
nothing else.
If we again declare feature freeze then that becomes R14-alpha.
That's exactly why I suggested tagging R14.0.0-alpha: to establish a point which is
going to be the base of R14.0.0.
It is basically saying: "let's declare R14 feature-freeze, no more fancy stuff,
no more new apps, no more enhancement will go in R14.0.0." But we make this
"stick in the code", not just in words.
We focus on R14.0.0-alpha branch and try to get to R14.0.0 release in a timely manner.
Without a fixed base to work on, every new commit there is the possibility to add new bugs
and new problems, which would cause even more delay to R14 :-( If you want an example:
last year in Jul, soft and hard freeze were declared for R14. Then came some renames, then
some fixes, then more renames, some enhancement and so on....
We need to avoid the same mistakes.
Michele
1:29 p.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
Hi Guys,
On Monday 24 February 2014 09:59:57 Michele Calgaro wrote:
Slavek, Darrell,
all three of us are saying the same thing: let's focus on the tasks
needed to release R14.0.0
There are lots out here waiting patiently for R14 !
--
Best Regards:
Baron.
2:15 p.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
Dne po 24. února 2014 Michele Calgaro napsal(a):
Slavek, Darrell,
all three of us are saying the same thing: let's focus on the tasks
needed to release R14.0.0
Highlighting both of your comments:
That's exactly why I suggested tagging R14.0.0-alpha: to establish a
point which is going to be the base of R14.0.0. It is basically saying:
"let's declare R14 feature-freeze, no more fancy stuff, no more new
apps, no more enhancement will go in R14.0.0." But we make this "stick
in the code", not just in words. We focus on R14.0.0-alpha branch and
try to get to R14.0.0 release in a timely manner.
Without a fixed base to work on, every new commit there is the
possibility to add new bugs and new problems, which would cause even
more delay to R14 :-( If you want an example: last year in Jul, soft
and hard freeze were declared for R14. Then came some renames, then
some fixes, then more renames, some enhancement and so on.... We need
to avoid the same mistakes.
Michele
Yes, I know that after announced freeze was commits with big changes and
renaming. However, it was us who wanted to push it as part R14.0.0. We
thought that at the time was right. Just as we now consider it right to
refrain from any such major changes. And because at this time we are all
working to finalize R14.0.0, it should be no one who would carry out
aggressive hacking.
I think it would be sufficient if we will soon announce the renewal of the
state of soft-freeze. 28. February seems good date.
Note: For final R14.0.0 we should solve NetworkManager8 support, which
could represent a piece of code that should be pushed, even if the
soft-freeze.
--
Slavek
I suggest
at this point to completely stop the debate on new
applications and pursue exclusively the tasks necessary for R14.0.0.
At one time we were at feature freeze but that got lost soon
thereafter. Perhaps we should again declare a feature freeze: all of
us should focus on R14.0.0 and nothing else. If we again declare
feature freeze then that becomes R14-alpha.
3:55 p.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
I think it would be sufficient if we will soon
announce the renewal of the
state of soft-freeze. 28. February seems good date.
Sounds good to me. Actually it is the same day I proposed in the etherpad a couple of
hours ago :-)
I would still prefer to have a branch for it, but it is not strictly necessary as long as
we all agree to avoid potentially "dangerous" commits.
After declaring the soft-freeze we should:
1) refrain from any kde->tde rename
2) refrain from renaming/moving files around, unless strictly needed. Specifically I would
like to avoid new FTBFS such as those that were recently created when docs and icons were
updated
3) refrain from adding new apps/enhancement to the trunk
4) create a realistic list of bugs that have to be fixed for R14.0.0 (we can build upon
the existing etherpad), review it together and soft-freeze the list as well. Only critical
issues could then be added to such list.
Note: For final R14.0.0 we should solve NetworkManager8
support, which
could represent a piece of code that should be pushed, even if the soft-freeze.
It's ok, just put that in the list.
Cheers
Michele
5:31 p.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
I think it would be sufficient if we will soon
announce the renewal of the
state of soft-freeze. 28. February seems good date.
Updated the etherpad to Feb. 28 for the first soft freeze.
By the way, with respect to our eagerness to release R14.0.0, we are not even close to any
records for time between releases. I believe the Enlighentment people hold some kind of
record. Closer to home, the Xfce folks have gone two years without a release.
So let's just get R14 done right. :)
--
Darrell
26 Feb
26 Feb
2:54 p.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
Dne po 24. února 2014 Darrell napsal(a):
I have one suggestion to date for the soft-freeze: move it from Friday to
Monday. After all, during the week we were more busy by work
responsibilities.
What do you think?
--
Slavek
I think it
would be sufficient if we will soon announce the renewal
of the state of soft-freeze. 28. February seems good date.
Updated the etherpad to Feb. 28 for the first soft freeze.
By the way, with respect to our eagerness to release R14.0.0, we are
not even close to any records for time between releases. I believe the
Enlighentment people hold some kind of record. Closer to home, the Xfce
folks have gone two years without a release.
So let's just get R14 done right. :)
5:25 p.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
On 02/26/2014 08:54 AM, Slávek Banko wrote:
I have one suggestion to date for the soft-freeze:
move it from Friday to
Monday. After all, during the week we were more busy by work
responsibilities.
What do you think?
Sounds like a good idea.
--
David C. Rankin, J.D.,P.E.
6:52 p.m.
New subject: [trinity-devel] Is is time for R14.0.0-alpha (which is intended as "before RC1")?
On Wed February 26 2014 8:54:07 am Slávek Banko wrote:
Dne po 24. února 2014 Darrell napsal(a):
I have one suggestion to date for the soft-freeze: move it from Friday to
Monday. After all, during the week we were more busy by work
responsibilities.
What do you think?
Fair enough: Monday March 3.
Darrell
I think
it would be sufficient if we will soon announce the renewal
of the state of soft-freeze. 28. February seems good date.
Updated the etherpad to Feb. 28 for the first soft freeze.
By the way, with respect to our eagerness to release R14.0.0, we are
not even close to any records for time between releases. I believe the
Enlighentment people hold some kind of record. Closer to home, the Xfce
folks have gone two years without a release.
So let's just get R14 done right. :)
24 Feb
24 Feb
6:57 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
(1957). If you folks want additional apps, I have a
long list of KDE3 apps that could be added. I still have access to the >sources and
Slackware build scripts.
Darrell,
could you file a new bug report with the list of apps and source references that you have?
It would be a kind of "meta" bug.
Those apps may or may not be included in the trunk later on (past R14.0.0. release is
possible), but it would be interesting in seeing what is available. Perhaps what is
useless for a user, it is useful for other, and viceversa :)
Cheers
Michele
7:40 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Mon February 24 2014 12:57:21 am Michele Calgaro wrote:
Perhaps some user feedback before I do that. The files are easy to browse right now:
http://repository.slacky.eu/slackware-12.2/
Slackware 12.2 was the last Slackware release that supported KDE 3.5.10.
Considering the time span since these packages were released and unmaintained, I suspect
many of the packages will need more work than just TQt3 conversion. A handful are still
supported in KDE4 so we would need to find applicable patches to backport. Some of the
apps probably are best not merging as separate apps but pulling good features into
Trinity, such as kpager2.
If we create an R14-alpha branch then merging new apps belongs in the main trunk. My great
concern is quality control, as I shared in my previous check list. Much like the very old
Fram oil filter commercial years ago, these old apps mean we pay now or pay later with
respect to bugs biting us in the backside. I rather we have a good quality control check
list up front to minimize surprises later.
--
Darrell
(1957). If you
folks want additional apps, I have a long list of KDE3 apps that could be added. I still
have access to the >sources and Slackware build scripts.
Darrell,
could you file a new bug report with the list of apps and source references that you
have? It would be a kind of "meta" bug.
Those apps may or may not be included in the trunk later on (past R14.0.0. release is
possible), but it would be interesting in seeing what is available. Perhaps what is
useless for a user, it is useful for other, and viceversa :)
8:13 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
http://repository.slacky.eu/slackware-12.2/
Slackware 12.2 was the last Slackware release that supported KDE 3.5.10.
Thanks
Darrell, let's see other users opinions as well.
If we create an R14-alpha branch then merging new apps
belongs in the main trunk.
My great concern is quality control, as I shared in my previous check list.
Fully
agree on both points. Actually adding new apps should be part of the R14.y.0 branch, not
even R14.0.x maintenance releases.
Cheers
Michele
8:27 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Mon February 24 2014 2:13:38 am Michele Calgaro wrote:
I agree: R14.y.0, not R14.0.y.
If we had a how-to with the TQt3 conversion, then add my quality control check list to
that information, we could invite anybody to add desirable apps and start the grunt work.
But the additions would remain in the respective bug report as a patch until the main team
is ready for that next step.
--
Darrell
http://repository.slacky.eu/slackware-12.2/
Slackware 12.2 was the last Slackware release that supported KDE 3.5.10.
Thanks
Darrell, let's see other users opinions as well.
If we create an R14-alpha branch then merging new
apps belongs in the main trunk.
My great concern is quality control, as I shared in my previous check list.
Fully
agree on both points. Actually adding new apps should be part of the R14.y.0 branch, not
even R14.0.x maintenance releases.
8:34 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Monday 24 of February 2014 09:27:02 Darrell wrote:
I agree: R14.y.0, not R14.0.y.
If we had a how-to with the TQt3 conversion, then add my quality control
check list to that information, we could invite anybody to add desirable
apps and start the grunt work. But the additions would remain in the
respective bug report as a patch until the main team is ready for that next
step.
François has a lot of experience and many applications have already been
successfully prepared. Indeed, his experience showed in the preparation
KXMLEditor. I believe that it is currently François best candidate for the
preparation of new applications.
--
Slavek
8:37 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
François has a lot of experience and many applications
have already been
successfully prepared. Indeed, his experience showed in the preparation
KXMLEditor. I believe that it is currently François best candidate for the
preparation of new applications.
Sounds good.
Francois, if you draft a how-to, I'll test and edit the English. Then I'll post to
the wiki or new web site.
--
Darrell
11:32 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Mon, 24 Feb 2014 08:13:38 +0000 (GMT)
Michele Calgaro <michele.calgaro(a)yahoo.it> wrote:
There's also the Gentoo kde-sunset overlay, browseable from
https://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary
(or use http://gpo.zugaina.org/Overlays/kde-sunset to just get a list of
applications with one-line summaries of what they're for).
There is some light maintenance going on there, as you can see from the
commit list. Patches are in the open in the git repository (check the files/
subdirectory for each application).
Agree with you both here.
E. Liddell
http://repository.slacky.eu/slackware-12.2/
Slackware 12.2 was the last Slackware release that supported KDE 3.5.10.
Thanks
Darrell, let's see other users opinions as well. If we create
an R14-alpha branch then merging new apps belongs in the main trunk.
My great concern is quality control, as I shared in my previous check list.
Fully
agree on both points. Actually adding new apps should be part of the R14.y.0 branch, not
even R14.0.x maintenance releases.
25 Feb
25 Feb
3:55 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/24/2014 01:40 AM, Darrell wrote:
On Mon February 24 2014 12:57:21 am Michele Calgaro
wrote:
Perhaps some user feedback before I do that. The files are easy to browse
right now:
http://repository.slacky.eu/slackware-12.2/
Slackware 12.2 was the last Slackware release that supported KDE 3.5.10.
I would vote for (anything the rest want) and:
database/kmysqladmin/
desktop/domino/
graphic/qcad/ # A true vector based CAD for linux
scientific/celestia/
security/keepassx/ # if you don't use it -- you should, it's that good...
# no need to add to tree, this slack version is Qt4
# as well. (it's available outside TDE). Screenshot:
http://www.3111skyline.com/dl/dt/trinity/ss/keepassx.jpg
utilities/ksendfax/ # very capable fax tool (hdw modem needed)
(1957).
If you folks want additional apps, I have a long list of KDE3
apps that could be added. I still have access to the >sources and
Slackware build scripts.
Darrell, could you file a new bug report with the list of apps and source
references that you have? It would be a kind of "meta" bug. Those apps may
or may not be included in the trunk later on (past R14.0.0. release is
possible), but it would be interesting in seeing what is available. Perhaps
what is useless for a user, it is useful for other, and viceversa :) 
Considering the time span since these packages were
released and
unmaintained, I suspect many of the packages will need more work than just
TQt3 conversion. A handful are still supported in KDE4 so we would need to
find applicable patches to backport. Some of the apps probably are best not
merging as separate apps but pulling good features into Trinity, such as
kpager2.
If we create an R14-alpha branch then merging new apps belongs in the main
trunk. My great concern is quality control, as I shared in my previous check
list. Much like the very old Fram oil filter commercial years ago, these old
apps mean we pay now or pay later with respect to bugs biting us in the
backside. I rather we have a good quality control check list up front to
minimize surprises later.
I like the alpha branch, or why not just tag is a 14.0.1?
--
David C. Rankin, J.D.,P.E.
3:25 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/23/2014 05:33 AM, Michele Calgaro wrote:
Scribus:
open bug report 1857.
David, when you want a program to be added to the repo, just file a bug report for it,
it's the best way to "don't forget it".
Michele
Will, do. I generally try to open feature requests, but as you can see with 881,
they don't move to fast :)
--
David C. Rankin, J.D.,P.E.
3:48 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
Will, do. I generally try to open feature requests,
but as you can see with 881,
they don't move to fast :)
This was one of many bug reports that Calvin assigned to himself. Does he have any
intention of following through?
(I too would like to see 881 completed.)
--
Darrell
3:58 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/24/2014 09:48 PM, Darrell wrote:
This was one of many bug reports that Calvin assigned
to himself. Does he have any intention of following through?
(I too would like to see 881 completed.)
I think you and I should take it and get it done for R14. I don't think Calvin
has a full R14 install right now to test on. I use it all the time. In fact the
list of Mediawiki templates I sent E. was sorted via katesort. I also have the
suse srpm for it, so building it should be easy.
I'll see if Slavek has time to look at the systemd issue. I'm basically chasing
my tail. (3 hours research, I new line of code to try, 3 more hours research...)
--
David C. Rankin, J.D.,P.E.
4:09 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
I've been prodding my way through getting a building system now to test
tde. I'm particularly busy these last 12 months
On Feb 24, 2014 10:58 PM, "David C. Rankin"
<drankinatty(a)suddenlinkmail.com>
wrote:
On 02/24/2014 09:48 PM, Darrell wrote:
This was one of many bug reports that Calvin
assigned to himself. Does
he have any intention of following through?
(I too would like to see 881 completed.)
I think you and I should take it and get it done for R14. I don't think
Calvin
has a full R14 install right now to test on. I use it all the time. In
fact the
list of Mediawiki templates I sent E. was sorted via katesort. I also have
the
suse srpm for it, so building it should be easy.
I'll see if Slavek has time to look at the systemd issue. I'm basically
chasing
my tail. (3 hours research, I new line of code to try, 3 more hours
research...)
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
4:17 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On Mon February 24 2014 10:09:36 pm Calvin Morrison wrote:
I've been prodding my way through getting a
building system now to test
tde. I'm particularly busy these last 12 months
All of us are busy. If you are not going to follow through or can't follow through
because of obligations then at least reset the assignments on the affected bug reports.
--
Darrell
4:30 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
If you feel motivated to change the assigned person, you better also
reassign all the ones Tim is assigned too which he hasn't made progress on.
The designation doesnt prevent anything from happening at all... Like I
said I'm working in getting tde up and running.
Calvin
On Feb 24, 2014 11:17 PM, "Darrell" <darrella(a)clovermail.net> wrote:
On Mon February 24 2014 10:09:36 pm Calvin Morrison
wrote:
I've been prodding my way through getting a
building system now to test
tde. I'm particularly busy these last 12 months
All of us are busy. If you are not going to follow through or can't follow
through because of obligations then at least reset the assignments on the
affected bug reports.
--
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
5:59 a.m.
New subject: R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
All of us are busy. If you are not going to follow
through or can't follow through because of obligations then
at least reset the assignments on the affected bug reports.
Since we are on the subject, one of my ideas was that after we declare R14 feature freeze
(this friday), we go through the list of assigned bugs and reset to NEW those were nothing
has been done for a few months (say 4 or more months) and no patches are available. If
later the same person (or another person) has time for that bug, he can reassign the bug
to himself.
Any objections?
Michele
4:16 a.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
I think you and I should take it and get it done for
R14. I don't think Calvin
has a full R14 install right now to test on. I use it all the time. In fact the
list of Mediawiki templates I sent E. was sorted via katesort. I also have the
suse srpm for it, so building it should be easy.
What do you mean all the time? Do you have a KDE3 environment or have you already
converted the plugin to tqt3?
tdeaddons/kate would be an appropriate location but I need a patch attached to 881 so I
can test before pushing.
Earlier today the group set Feb. 28 as the date for a soft freeze. No new features after
that date, only bug fixes. Any patch attached to 881 after that date will still be usable
by those who build their own packages but won't get pushed to git until after R14.0.0
is released, which would then become part of R14.0.1.
--
Darrell
8:29 p.m.
New subject: [trinity-devel] SOLVED : Re: [trinity-devel] R: [trinity-devel] KXMLedit is MISSING from TDE - Slavek can you convert/add?
On 02/24/2014 10:16 PM, Darrell wrote:
What do you mean all the time? Do you have a KDE3
environment or have you
already converted the plugin to tqt3?
No, my laptop is suse/kde3, (at least the harddrive that is currently in it),
tdeaddons/kate would be an appropriate location but I
need a patch attached
to 881 so I can test before pushing.
Earlier today the group set Feb. 28 as the date for a soft freeze. No new
features after that date, only bug fixes. Any patch attached to 881 after
that date will still be usable by those who build their own packages but
won't get pushed to git until after R14.0.0 is released, which would then
become part of R14.0.1.
I'll tear into the srpm, the sort priority was behind getting TDE working on
systemd without leaving lots of stray tdeio processes running. That has taken
longer than I originally thought (much longer).
--
David C. Rankin, J.D.,P.E.
3720
days inactive
3725
days old
63 comments
8 participants
participants (8)
-
Baron -
Calvin Morrison -
Darrell -
David C. Rankin -
E. Liddell -
François Andriot -
Michele Calgaro -
Slávek Banko