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/kxmledi...
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
Added to bugszilla bug 1955
Michele
On 02/22/2014 08:55 AM, Slávek Banko wrote:
On Saturday 22 of February 2014 15:39:04 Michele Calgaro wrote:
Added to bugszilla bug 1955
Michele
Great, thank you.
Slavek
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...
Le 22/02/2014 18:58, David C. Rankin a écrit :
On 02/22/2014 08:55 AM, Slávek Banko wrote:
On Saturday 22 of February 2014 15:39:04 Michele Calgaro wrote:
Added to bugszilla bug 1955
Michele
Great, thank you.
Slavek
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 [...]
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 18:58:10 David C. Rankin wrote:
On 02/22/2014 08:55 AM, Slávek Banko wrote:
On Saturday 22 of February 2014 15:39:04 Michele Calgaro wrote:
Added to bugszilla bug 1955
Michele
Great, thank you.
Slavek
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...
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 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 --
On 02/22/2014 12:10 PM, Slávek Banko wrote:
A further two notes:
- 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.
- 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.
On 02/22/2014 12:45 PM, David C. Rankin wrote:
On 02/22/2014 12:10 PM, Slávek Banko wrote:
A further two notes:
- 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.
- 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.
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?
On 02/22/2014 12:53 PM, David C. Rankin wrote:
On 02/22/2014 12:45 PM, David C. Rankin wrote:
On 02/22/2014 12:10 PM, Slávek Banko wrote:
A further two notes:
- 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.
- 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.
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?
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?
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
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!
Le 22/02/2014 20:46, David C. Rankin a écrit :
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!
Bug report 1955 updated.
On 02/22/2014 02:13 PM, François Andriot wrote:
Le 22/02/2014 20:46, David C. Rankin a écrit :
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!
Bug report 1955 updated.
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 02:39 PM, David C. Rankin wrote:
On 02/22/2014 02:13 PM, François Andriot wrote:
Le 22/02/2014 20:46, David C. Rankin a écrit :
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!
Bug report 1955 updated.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
I am curious. What about quanta plus? Various kate plugins. Why a new app?
On 02/22/2014 06:17 PM, Darrell wrote:
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.
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.
I am curious. What about quanta plus? Various kate plugins. Why a new app?
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.
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.
On 02/22/2014 05:12 PM, Darrell wrote:
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:
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.
Convert as necessary to current TQt3 requirements. This process needs to be openly documented to encourage other people to perform some of the work.
Verify the package builds on at least three different distros. Typically Debian-based, RPM-based, and then an independent such as Arch or Slackware.
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.
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.
Verify the help handbook opens when selecting the handbook from the Help menu.
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.
Verify a Help button is available in the configuration dialogs.
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.
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.
Verify i18n files are reviewed or added.
This is a draft 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
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.
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.
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.
On Sat February 22 2014 10:53:48 pm Darrell wrote:
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.
Looks like 1.3.3.14 was Qt3.
Version 1.3.5 was the first Qt4 version.
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
On Sun, 23 Feb 2014 07:07:38 +0000 (GMT) Michele Calgaro michele.calgaro@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
On Sunday 23 of February 2014 13:32:12 Michele Calgaro wrote:
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
Development sounds like a good place.
On 02/23/2014 06:32 AM, Michele Calgaro wrote:
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
Development is find for both. All text editors in Editors, all non-text/xml editors in Development works.
On 02/22/2014 10:53 PM, Darrell wrote:
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.
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.
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
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.
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.
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.
On Monday 24 of February 2014 08:29:40 Darrell wrote:
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.
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.
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.
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
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 !
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:
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
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.
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
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. :)
Dne po 24. února 2014 Darrell napsal(a):
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. :)
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?
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.
On Wed February 26 2014 8:54:07 am Slávek Banko wrote:
Dne po 24. února 2014 Darrell napsal(a):
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. :)
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
(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
On Mon February 24 2014 12:57:21 am Michele Calgaro wrote:
(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 :)
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.
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
On Mon February 24 2014 2:13:38 am Michele Calgaro wrote:
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.
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.
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.
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.
On Mon, 24 Feb 2014 08:13:38 +0000 (GMT) Michele Calgaro michele.calgaro@yahoo.it wrote:
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.
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).
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.
Agree with you both here.
E. Liddell
On 02/24/2014 01:40 AM, Darrell wrote:
On Mon February 24 2014 12:57:21 am Michele Calgaro wrote:
(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 :)
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)
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?
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 :)
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.)
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...)
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@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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
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.
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@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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
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
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.
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).
-
Baron -
Calvin Morrison -
Darrell -
David C. Rankin -
E. Liddell -
François Andriot -
Michele Calgaro -
Slávek Banko