Re: [kde-doc-english] Making KDocTools independent of KArchive
Albert Astals Cid wrote: El Diumenge, 29 de setembre de 2013, a les 12:14:49, David Faure va escriure: On Monday 23 September 2013 20:23:13 Albert Astals Cid wrote: So we don't have a man page anymore? Debian will be happy :D Also we're losing the i18n-zation side of the man page, which the current -- help does not have. What do non-kde projects do? Write a man page by hand and translate it by hand? Or do they use .po files somehow? I've no clue, I don't participate in any non-kde project that has translated man pages. It seems po4a-gettextize knows how to create a .pot file from a manpage file. If anyone wants to give it a try to integrate into our l10n workflow... Still you'd lose the hability to say convert the manpage to an html file or a pdf like we have right now since it would not be a docbook anymore. We also lose our custom entities. On the other side, manpage generation does not require a final compression to bz2 (which is used for the htmls generated for the documentation), so maybe it could be possible to split something more? Just thinking aloud. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Well if this is okay, you could just remove the KDE-specific DTDs and entities from the relevant docbook files and just call xsltproc manually. IIRC xml2pot and friends are not too picky about what sort of XML gets fed into them, so scripty should just continue to make POTs out of these plain docbooks just as well as it handles normal KDE ones. But, the script that generates kde-l10n-foo tarballs probably just calls meinproc so some work may be needed on that side to get translation working properly. (Whether that be fixing meinproc to handle non-KDE customized docbooks if it doesn't already or just fixing that script to use xsltproc where needed.) -T.C. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Monday 23 September 2013 20:23:13 Albert Astals Cid wrote: So we don't have a man page anymore? Debian will be happy :D Also we're losing the i18n-zation side of the man page, which the current -- help does not have. What do non-kde projects do? Write a man page by hand and translate it by hand? Or do they use .po files somehow? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
El Diumenge, 29 de setembre de 2013, a les 12:14:49, David Faure va escriure: On Monday 23 September 2013 20:23:13 Albert Astals Cid wrote: So we don't have a man page anymore? Debian will be happy :D Also we're losing the i18n-zation side of the man page, which the current -- help does not have. What do non-kde projects do? Write a man page by hand and translate it by hand? Or do they use .po files somehow? I've no clue, I don't participate in any non-kde project that has translated man pages. It seems po4a-gettextize knows how to create a .pot file from a manpage file. If anyone wants to give it a try to integrate into our l10n workflow... Still you'd lose the hability to say convert the manpage to an html file or a pdf like we have right now since it would not be a docbook anymore. Cheers, Albert P.S: Added the docu people ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Wednesday 25 September 2013 01:13:05 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 14:09:57, Kevin Ottens va escriure: On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure: On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. That's really weird, we have a solution that works, and you want to use something else? What does that gives us? That stuff in kde now depends in two docbook-to-manpage conversion tools instead of one? Are you sure that's an improvement? Well, as highlighted we have a dependency issue there, so it's either: 1) no docbook in tier 1 and tier 2 frameworks; 2) we use a different docbook to manpage tool for tier 1 and tier 2 frameworks. Why you guys don't treat e-c-m as a dependency for the tier system but treat kdoctools as one? Well, e-c-m is one too many for my taste to be honest. But we have no way around it I'm afraid. :-) I mean they are both prerequisites for the other modules (and if you remove KArchive from kdoctools as the thread title suggests both are 'non-kde'), aren't they? Indeed, that makes for a: 3) make kdoctool not depend on anything else from KDE Frameworks, and frameworks which have manpages can optionally use it. Makes for a kind of exception in the way we manage the dependencies so far, not sure I like this increase in complexity either. Personally I think I would aim for: * no docbook in tier 1; * remove the KArchive dependency of kdoctools (making it tier 1); * make it an optional dependencies for tier 2 and 3 frameworks which would need it. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Wednesday 25 September 2013, Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 14:09:57, Kevin Ottens va escriure: On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure: On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. That's really weird, we have a solution that works, and you want to use something else? What does that gives us? That stuff in kde now depends in two docbook-to-manpage conversion tools instead of one? Are you sure that's an improvement? Well, as highlighted we have a dependency issue there, so it's either: 1) no docbook in tier 1 and tier 2 frameworks; 2) we use a different docbook to manpage tool for tier 1 and tier 2 frameworks. Why you guys don't treat e-c-m as a dependency for the tier system but treat kdoctools as one? I mean they are both prerequisites for the other modules (and if you remove KArchive from kdoctools as the thread title suggests both are 'non-kde'), aren't they? Is kdoctools only a buildtime dependency or also a runtime dependency, i.e. is it a library which is linked against ? e-c-m is only needed at compile time. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Monday, September 23, 2013, Nicolás Alvarez wrote: On Monday, September 23, 2013, Kevin Ottens wrote: On Saturday 21 September 2013 15:25:27 Albert Astals Cid wrote: El Dissabte, 21 de setembre de 2013, a les 11:15:52, Stephen Kelly va escriure: Albert Astals Cid wrote: Anyway as I was chatting with Aleix yesterday, kdoctools being a tier1 framework is not enough since kconfig has docbook files (e.g. man page of kconfig_compiler) so we need a tier0 here ;-) Where is kconfig now? Do I really need to do an ls for you? What I was trying to get at is that you seem to be implying that kconfig depends on kdoctools (ie, a tier1 depends on a tier2), therefore kdoctools can't be tier1. I don't follow that logic. Well, kconfig depends on kdoctools because as I said there is a docbook for the kconfig_compiler manpage. So yes, there is a tier1 that depends on a tier2. That if as I understand we plan to ship the kconfig_compiler manpage together with the kconfig framework tarball. Well, I'm not sure we want to do that. This docbook seems useful only because kconfig_compiler --help does a poor job at documenting itself. So what about completing kconfig_compiler --help output to make it useful and get rid of the docbook? To me it looks like most of the docbook files in kdelibs are pretty much in the same situation and I'd favor proper --help support there than adding a dependency on kdoctool. I assume making it an optional dependency (if not present, don't build the manpage) doesn't help, because the current tiers fully allow having kdoctools depend on kconfig, which would cause a circular dependency. What does kdoctools buy us here? Maybe we can use a third-party docbook The Gmail mobile app is amazingly bad. Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... -- Nicolás -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure: On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. That's really weird, we have a solution that works, and you want to use something else? What does that gives us? That stuff in kde now depends in two docbook-to-manpage conversion tools instead of one? Are you sure that's an improvement? Albert Cheers. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure: On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. That's really weird, we have a solution that works, and you want to use something else? What does that gives us? That stuff in kde now depends in two docbook-to-manpage conversion tools instead of one? Are you sure that's an improvement? Well, as highlighted we have a dependency issue there, so it's either: 1) no docbook in tier 1 and tier 2 frameworks; 2) we use a different docbook to manpage tool for tier 1 and tier 2 frameworks. Pick your poison. But we can't keep said dependency issue. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Tue, Sep 24, 2013 at 2:09 PM, Kevin Ottens er...@kde.org wrote: On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure: On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. That's really weird, we have a solution that works, and you want to use something else? What does that gives us? That stuff in kde now depends in two docbook-to-manpage conversion tools instead of one? Are you sure that's an improvement? Well, as highlighted we have a dependency issue there, so it's either: 1) no docbook in tier 1 and tier 2 frameworks; 2) we use a different docbook to manpage tool for tier 1 and tier 2 frameworks. Pick your poison. But we can't keep said dependency issue. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Maybe we can bundle the generated documentation? I think we're making it more of a problem than actually is... Maybe the problem here is considering kdoctools as a framework instead of a tool set. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Tuesday 24 September 2013 15:05:56 Aleix Pol wrote: On Tue, Sep 24, 2013 at 2:09 PM, Kevin Ottens er...@kde.org wrote: On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: Are you sure that's an improvement? Well, as highlighted we have a dependency issue there, so it's either: 1) no docbook in tier 1 and tier 2 frameworks; 2) we use a different docbook to manpage tool for tier 1 and tier 2 frameworks. Pick your poison. But we can't keep said dependency issue. Maybe we can bundle the generated documentation? I think we're making it more of a problem than actually is... Maybe the problem here is considering kdoctools as a framework instead of a tool set. That's indeed a solution. We could deal with those man pages in the same way than we deal with parsers using flex and yacc... I don't like that much as that forces us to commit the resulting file. But maybe that's the proper way to make everyone happy in that case. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
Maybe we can bundle the generated documentation? Distributions in general don't want pregenerated anything. /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
El Dimarts, 24 de setembre de 2013, a les 14:09:57, Kevin Ottens va escriure: On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure: On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. That's really weird, we have a solution that works, and you want to use something else? What does that gives us? That stuff in kde now depends in two docbook-to-manpage conversion tools instead of one? Are you sure that's an improvement? Well, as highlighted we have a dependency issue there, so it's either: 1) no docbook in tier 1 and tier 2 frameworks; 2) we use a different docbook to manpage tool for tier 1 and tier 2 frameworks. Why you guys don't treat e-c-m as a dependency for the tier system but treat kdoctools as one? I mean they are both prerequisites for the other modules (and if you remove KArchive from kdoctools as the thread title suggests both are 'non-kde'), aren't they? Cheers, Albert Pick your poison. But we can't keep said dependency issue. Regards. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Making KDocTools independent of KArchive
KDocTools depends on KArchive so that it can write cache files. Those files are currently written as .bz2 files, which is why KArchive is needed. However, I can see no reason why qCompress and qUncompress would not do the job just as well. Porting to those would make KDocTools a tier1 framework. Any reason not to do that? Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
El Dissabte, 21 de setembre de 2013, a les 10:25:59, Stephen Kelly va escriure: KDocTools depends on KArchive so that it can write cache files. Those files are currently written as .bz2 files, which is why KArchive is needed. However, I can see no reason why qCompress and qUncompress would not do the job just as well. Porting to those would make KDocTools a tier1 framework. Any reason not to do that? Are you adapting the stuff that expects a bz2 file to work with qCompress? Anyway as I was chatting with Aleix yesterday, kdoctools being a tier1 framework is not enough since kconfig has docbook files (e.g. man page of kconfig_compiler) so we need a tier0 here ;-) Cheers, Albert Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
El Dissabte, 21 de setembre de 2013, a les 10:44:35, Albert Astals Cid va
escriure:
El Dissabte, 21 de setembre de 2013, a les 10:39:22, Stephen Kelly va
escriure:
Albert Astals Cid wrote:
El Dissabte, 21 de setembre de 2013, a les 10:25:59, Stephen Kelly va
escriure:
KDocTools depends on KArchive so that it can write cache files. Those
files are currently written as .bz2 files, which is why KArchive is
needed.
However, I can see no reason why qCompress and qUncompress would not do
the job just as well. Porting to those would make KDocTools a tier1
framework. Any reason not to do that?
Are you adapting the stuff that expects a bz2 file to work with
qCompress?
No. I'm saying it can store and load .bin files which are processed with
q{Unc,C}ompress.
There does not seem to be any need or reason for them to be .bz2.
There is no need for it to be a .bz2 other than it is what it does and if
you change it you are going to break stuff that uses it. So yes, no
reason.
Anyway as I was chatting with Aleix yesterday, kdoctools being a tier1
framework is not enough since kconfig has docbook files (e.g. man page
of kconfig_compiler) so we need a tier0 here ;-)
Where is kconfig now?
Do I really need to do an ls for you?
Sorry, this was uncalled for, the correct answer should have been
http://community.kde.org/Frameworks/Overview
Please do accept my apologies.
Cheers,
Albert
Cheers,
Albert
Thanks,
Steve.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
El Dissabte, 21 de setembre de 2013, a les 11:15:52, Stephen Kelly va
escriure:
Albert Astals Cid wrote:
No. I'm saying it can store and load .bin files which are processed with
q{Unc,C}ompress.
There does not seem to be any need or reason for them to be .bz2.
There is no need for it to be a .bz2 other than it is what it does and if
you change it you are going to break stuff that uses it. So yes, no
reason.
What would break? Everything that reads and writes those files is in-tree.
Right, i tought khelpcenter did some of the decoding, but it's done via
meinproc too.
Anyway as I was chatting with Aleix yesterday, kdoctools being a tier1
framework is not enough since kconfig has docbook files (e.g. man
page of kconfig_compiler) so we need a tier0 here ;-)
Where is kconfig now?
Do I really need to do an ls for you?
What I was trying to get at is that you seem to be implying that kconfig
depends on kdoctools (ie, a tier1 depends on a tier2), therefore kdoctools
can't be tier1. I don't follow that logic.
Well, kconfig depends on kdoctools because as I said there is a docbook for
the kconfig_compiler manpage.
So yes, there is a tier1 that depends on a tier2. That if as I understand we
plan to ship the kconfig_compiler manpage together with the kconfig framework
tarball.
Cheers,
Albert
Thanks,
Steve.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
