tde-devels January 2014

devels@trinitydesktop.org

16 participants
197 discussions

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

10 years, 4 months

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

10 years, 4 months

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

10 years, 4 months

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

10 years, 4 months

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

10 years, 4 months

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

10 years, 4 months

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

10 years, 4 months

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

by Darrell Anderson

>I added renaming rbkdeapi => rbtdeapi, rbkdesh => rbtdesh. > >The patch is large, so it is possible that we overlooked >something. >However, due to size of the patch, I consider it better first to >push >this patch to GIT and then if we find some problems, solve them as >additional patches. > >What is your opinion? That is what I thought too. There might be some corner cases missed in a patch this large, but we need to have a starting point. So push the monster. Not to sound pedantic, but that is one reason I keep asking for a simple how-to for guiding users with testing tdebindings. There are some test files in the sources but I never got them to function. Darrell

10 years, 4 months

Re: [trinity-devel] Another r14-xdg-update script patch

by Darrell Anderson

>Small update: Updated date-tag conditions for the new rules. >Renaming >tdestyle encapsulated as a separate rule - to separate date-tag >condition. Thank you. Pushed to git in commit 75561520. Darrell

10 years, 4 months

[trinity-devel] R14 press information

by Michael Henry

I happened to be browsing and stumbled across this: http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blo… In it, the journalist shows how the press kit of openSUSE is an example for all to follow. Here is a ling to said press kit: https://github.com/openSUSE/Press-Kit/zipball/12.3 Note that it is 37 MB. Since the project was looking for testimonials, I post this so it might generate some new ideas. Shalom -- Bro. Michael Henry Associate Pastor Monticello Christian Church 1 Timothy 1:15 "This is a faithful saying, and worthy of all acceptation, that Messiah Jesus came into the world to save sinners; of whom I am chief."

10 years, 4 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels January 2014