tde-devels

devels@trinitydesktop.org

1 participants
3754 discussions

by Darrell Anderson

>> Hello, there was too much KDE/TDE renaming in kscope, causing FTBFS at >> this time. >> >> The "KDE_IS_VERSION" macro is defined in "admin/acinclude.m4.in" >Fixed in GIT hash 7d55c452. >Thank you for your heads up. Sorry about that! I checked the full source tree. Looks like that was the only inadvertent KDE_IS_VERSION->TDE_IS_VERSION conversion. Darrell

11 years

Commit web page is not updating

by Darrell Anderson

The last update was Jan 8. Darrell

11 years

kscope FTBFS

by François Andriot

Hello, there was too much KDE/TDE renaming in kscope, causing FTBFS at this time. Here it is: http://git.trinitydesktop.org/cgit/kscope/commit/src/editorpage.cpp?id=974a… The "KDE_IS_VERSION" macro is defined in "admin/acinclude.m4.in" . François

11 years

Re: [trinity-devel] Slavek: Digikam and Showfoto help handbook files are available

by Darrell Anderson

>And what if we incorporate documentation for all languages into >an existing >git repository digikam and generate documentation could be done as >build >options? For example --with-doc and --with-doc-i18n or --without- >doc and --without-doc-i18n. That could be palatable. On reflection, I notice there are some apps that automatically include i18n docs when building the package. For example, amarok and kipi-plugins. Pushing the digikam docs into the existing digikam sources would be no different. If we add configuration options, the default should be --with- doc=true and --with-doc-i18n=false. Using --with-doc=true as a default ensures at least the English handbook is built with the standard package, just like most Trinity apps. Yet explicitly adding the --with-doc option allows for not building the docs. For example when people prefer building minimal footprint packages. If we add those configuration options then we should do likewise for all affected apps like amarok and kipi-plugins. So how about this: I push the digikam docs into the existing digikam sources. Right now that means all i18n docs are compiled when compiling digikam. No different than amarok and kipi-plugins. I open a bug report to add --with-doc and --with-doc-i18n configuration options to all Trinity apps, and equivalent cmake options. Darrell

11 years

Re: [trinity-devel] Slavek: Digikam and Showfoto help handbook files are available

by Darrell Anderson

>I acknowledge the history of the digikam help handbooks, but I'm >uncomfortable with that approach for Trinity. > >Let's split the English component only and merge that directly >into >the existing Digikam sources. That is how all other apps are >designed. I have already tested that. > >The remaining languages can move to a new module, >applications/digikam-doc-i18n. > >Most users who do not speak i18n languages don't want to install >all of those components just to obtain access to the >digikam/showfoto handbooks. Further, as is common with all other >Trinity apps, there should be a default handbook installed with >the package. :) I have this all tested. I have a single patch to push for the existing Digikam, which will build the English handbooks for Digikam and Showfoto. I have the proposed digikam-doc-i18n contents tested so only the i18n handbooks are built and installed. My digikam-doc-i18n files also include copies of the master admin and cmake files. All I need now is for somebody to create a new module in the main repository named digikam-doc-i18n. With the new upstream module I can push the whole directory and we'll be done. I would create the new module myself but I don't know whether I have permissions to do that and I also don't know all that is involved. Digikam and Showfoto handbooks standing by! Darrell

11 years

Re: [trinity-devel] Slavek: Digikam and Showfoto help handbook files are available

by Darrell Anderson

>Because the original package was purely a standalone package with >all >documentation, I suggest to keep it as well as a git module >applications/digikam-doc - all languages, including English. I acknowledge the history of the digikam help handbooks, but I'm uncomfortable with that approach for Trinity. Let's split the English component only and merge that directly into the existing Digikam sources. That is how all other apps are designed. I have already tested that. The remaining languages can move to a new module, applications/digikam-doc-i18n. Most users who do not speak i18n languages don't want to install all of those components just to obtain access to the digikam/showfoto handbooks. Further, as is common with all other Trinity apps, there should be a default handbook installed with the package. :) Darrell

11 years

Slavek: Digikam and Showfoto help handbook files are available

by Darrell Anderson

Slavek, Good news! I have the source files to compile help handbooks for Digikam and Showfoto. I compiled them successfully. Both are very nice manuals. :) Supported i18n languages for both digikam and showfoto: da, de, es, et, it, nl, sv. For digikam only: pt_BR, ru. Right now the sources are one tarball. As a test run I compiled digikam with all help files, including the i18n help files. The help files should be split similar to the k3b, gwenview, and koffice i18n files. The digikam help sources do not include po files. Only help files. On a second build run I removed the i18n files to create a basic digikam patch with only the English help files. No build problems. How do you want to merge the files into the source tree? I can merge the English help files directly into the digikam tree with one patch. No problem. For the i18n help files we need to create a new module in the git tree: applications/digikam-help-i18n or applications/digikam-i18n Let me know! Darrell

11 years

Re: [trinity-devel] tdebindings renaming/rebranding patch

by Darrell Anderson

On Wed, 08 Jan 2014 13:56:25 -0600 "Michael Henry" <bromichaelhenry(a)gmail.com> wrote: >So when do we get to test this? Right now. 'git pull' and rebuild tdebindings. Darrell

11 years

Re: [trinity-devel] R14 press information

by Darrell Anderson

>Nevertheless I also think that before releasing R14 we *do* need >to make an effort to update website/wiki/documentation in general. >Otherwise all the good work gone into R14 will be mostly wasted by >poor first user impression. My sentiments too. The current web site is functional --- no arguments from me. Yet a typical web user expects a little pizzazz from a web site. I agree with the well tested adage that we have only chance to make a first impression. R14 is a big release. Let's update the web site. Let's release R14 the right way. We don't have to get fancy. Just look around at other computer web sites. We don't have to engage in a major overhaul. Find a template we like and reorganize the links. Add come color to the web site. Long ago we had a discussion about updating the web site. I was asked to post recommendations. I don't remember whether the recommendations are in the dev mail list archives or an etherpad, but that would be a starting place. The grand challenge of these types of discussions: who will step forward and start working on mockups? I don't have that kind of experience. >If we want TDE to make a leap forward and be finally recognized as >a proper DE (and not as I read on several websites a "one man >show") we need to improve the public reception of TDE and updating >documentation and website are at the top of the list. Fact: for a long while Trinity was a "one man show." Then I came along and became constant nuisance and PITA, continually asking for changes and patches to run Trinity on Slackware. Tim and I busted butt doing that. Slowly Trinity transformed into a universal desktop rather than a desktop that started as being fine-tuned for Kubuntu. We've come a long way since then. That said, we not that far from still being a one man show. We have only three active developers. There are other people helping, but they c ome and go and only three people are continually knee deep in the mud. Improving upon the "one man show" image is a good goal. Updating the web site will help. >In the very worst case, once GIT code is R14 tagged, we should put >on hold development for a couple of weeks and focus on updating >documentation. Ideally though we should start earlier than that, >especially the handbooks. The etherpad was updated long ago to include those tasks. Darrell

11 years

Re: [trinity-devel] tdebindings renaming/rebranding patch

by Darrell Anderson

>The monster was pushed! >Including necessary changes in Debian/Ubuntu packaging. I hear the theme song from the movie Jaws playing in the background! Darrell

11 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels