tde-devels

devels@trinitydesktop.org

4 participants
3753 discussions

Centered or "Smart" Default Window Placement

by Darrell Anderson

I'm posting this question to both the developer's and user's list. Everybody's thoughts and comments are welcomed. Bug report 676 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=676) was submitted requesting that the default window placement be changed from "Smart" to Centered. A patch was provided to make that change. What do you think? The configuration option for window placement is found in Control Center, Desktop, Window Behavior, Moving tab. Please keep the conversation focused to the DEFAULT setting and not what you prefer. The default setting is used when a person uses Trinity for the first time and is still learning to use the desktop. For a default setting, keep in mind new users, users migrating from Windows, traditional window placement, user expectations, newbies, etc. This discussion is not about the merits of either option but which is best as a default for new users. Please --- if you don't know what the "Smart" option does, then don't speculate. :) Thanks much for your time! Darrell

13 years

Trinity User Guides Redux

by Darrell Anderson

A while back we discussed Trinity user guides. My schedule now looks good for digging deeper into providing that support. I also have reconsidered some elements of our past discussion. A proposed outline/table of contents will follow in another email. This is a lengthy read. I hope to receive commentary and discussion, but take your time to read and digest. :) ==================== Recap: ==================== We wanted to use a format that was easy to merge revisions into the GIT tree, which meant some kind of text based file system. We leaned toward ODF/ODT because the underlying file format is XML. Additionally that format lends well to anybody who wants to get involved because any word processor supporting ODT could be used. We want to support two output formats: PDF and HTML. PDF is important for portability. HTML is important to host online versions of the guides. Further, I envision us adding a TDE Handbook "device icon" that is a link to a local copy of the TDE user guide (kdebase?). A default new profile would have that icon on the desktop. We could have a T-Menu option for the guide too. KWord supports ODT, which supports the "eat your own dog food" philosophy. (We discussed that KWord's ODT support needs updating, but that is a different discussion.) Using KWord allows community members to participate with helping with documentation. I don't anticipate serious problems with contributors using the current KWord ODT "as is" because they will not be using complicated formatting. Further, we are not concerned with compatibility with other word processors. (Would somebody use Abiword to contribute to Trinity documentation?) Any user wanting to report typographical errors can copy and paste into their email client. If we use KWord to maintain the documentation, we noted that PDF output was not an issue because of the built-in PDF printing that comes with TDE. (Use File/Print rather than look for any 'PDF Export' or 'Save As' feature.) We more or less left the discussion with maintaining the guides in ODT format. Is that a good decision? I have been involved with technical writing for more than two decades. Word processors succeed in that environment only when custom templates are used along with a robust set of style tags. Allowing any manual formatting at all is a management and editorial nightmare. Although most people are familiar with using a word processor, only a minority of people outside of technical writers are familiar with templates and style tags. In the past whenever I designed templates for customers, I removed the manual formatting buttons from the toolbars and respective menu options. No manual formatting is allowed in any serious tech writing project. Further, there is a well known challenge with using a word processor to maintain our guides: generally, HTML output is awful and gets cluttered with useless tags. Any HTML we generate must validate all the time. I never have used a word processor that can provide that kind of HTML. There always is cleanup required. Certainly we could do that: maintain the guides in KWord and use some scripting to scrub the HTML. All of this sounds messy and labor intensive. Is there another way? We discussed the idea of using a markup language. Generally we were not in favor of using a markup language. One reason is the simpler markup languages do not support complicated features such as tables, text flows around graphics, etc. Another reason is we want to encourage community involvement and markup languages do not provide a familiar WYSIWYG interface. ==================== Proposal: ==================== There is one markup language that supports our GIT goals as well provide formatting flexibility: DocBook. DocBook is a subset of XML and popular in the free/libre world. A challenge with DocBook is few everyday users are going to use a markup language to contribute to documentation efforts. That should not be a problem because we agreed in our discussions that non team contributors can use whatever they want to submit revisions. They submit revision changes to the Trinity documentation team. Somebody on the documentation team would edit those submissions according to a Trinity style guide, convert those submissions into whatever format we use, and then merge to GIT. Sounds much like our first discussion: markup or word processor? Both. For community members who want to help with documentation, we create a KWord ODT template with known style tags. If possible we design the template toolbar and menus to prevent manual formatting. A premade template will satisfy our desire to make the process easier for community members. A template and style tags provides consistency. Because many people are unfamiliar with using style tags, we write a how-to. Using style tags is easy and after people see how style tags operate they wonder why anybody would use manual formatting for any serious project. Because the document template is based on style tags and not manual formatting, we use some scripting to convert that ODT/XML document to our DocBook templates. By the way, KWord 1.6 provides only nominal exporting support for DocBook (http://userbase.kde.org/Kword/1.6/DocBook). Some scripting attention would be needed to convert such documents. Yes, we could use that same template for our documentation team and maintain our user guides in that format. But we lose flexibility and we still have to scrub the files to validate any HTML output. But guess what? We have to use DocBook anyway --- for our Handbook help files. :) All of the TDE Handbook help files are in DocBook. Yes, all of them need serious revision attention, but that too is another discussion. The point is one way or another we will get our feet wet with DocBook. Why not include our user guides too? I envision down the road where we establish an ability to create user guides, help files, and other small "job aid" all from the same source files. Using such document sources means we could one day host all of our documentation on our web site in real time from the GIT tree. Using KWord for that kind of single sourcing would be cumbersome. KWord should be a stop gap only for community members who want to help but don't want to deal with DocBook. When done correctly, DocBook files can be massaged into high quality professional documentation, both PDF and HTML. As evidence, I recommend anybody interested in this topic to browse the OpenSuse KDE3 user guides (http://www.novell.com/documentation/opensuse103/). Both the PDF and HTML versions of their documentation are maintained with DocBook. As far as I can tell, just about all of the documentation teams working for the big distros use DocBook. Our user guide discussion reduces to what people on the Trinity documentation team want to use. I want to consider DocBook. In addition to making revisions with GIT easy, DocBook is neutral about outputs because that is controlled by backend processing. DocBook provides longevity. DocBook files are not affected should KWord no longer be supported in Trinity, which has been discussed. We have to deal with DocBook anyway because of the Handbook help files. Most of what we need is already available. All we need is to learn the processes. Oh, and document them too. :) ==================== Challenges: ==================== 1. Editing. Ideally we find a free/libre XML/DocBook editor that supports WYSIWYM (What You See Is What You Mean). WYSIWYM is different from WYSIWYG (What You See Is What You Get). The latter includes actual final page formatting directly on the screen. WYSIWYM does not. The focus with WYSIWYM is structure, which is exactly what DocBook supports. Yet an attractive feature about using a WYSIWYM interface is the writer sees some sort of visual representation of the text structure rather than raw markup. Think of WYSIWYM as a pseudo WYSIWYG. The visual feedback helps. Without a WYSIWYM interface, writers work in raw markup, which is not easy for many writers to do. There is the debate about eating one's own dog food. Trinity provides Quanta Plus. Quanta Plus supports DocBook (http://l10n.kde.org/docs/doc-primer/quanta.html) and is a well regarded tool for web development. Yet unlike HTML, Quanta Plus provides no WYSIWYM interface or display feedback for DocBook. That means writers on the documentation team learn to work in raw markup mode. Probably not a huge obstacle because the number of people on the Trinity documentation team will be but a few. I will ensure we have good documentation to use that tool for our specific needs. Yet with Quanta Plus we have a tool to claim we eat our own dog food. I'm not sure, but I think the KDE3 documentation team used Quanta Plus. I don't know what the OpenSuse documentation people use. (I'm curious to know.) I'm willing to overlook that Quanta Plus does not provide a WYSIWYM interface or display. Perhaps I'll add an enhancement request for that. :) Basically, most, if not all of these WYSIWYM interfaces use some kind of style sheet to interpret the underlying DocBook into basic HTML for the visual presentation and vice-versa. Remember that WYSIWYM is not a representation of final formatting but a visual representation of the document structure. Working in WYSIWYM is easier for most people than direct markup. Would be nice if we could add that feature to Quanta Plus. Although writing in raw markup --- even with Quanta Plus --- has a geek aspect that appeals to some, in the long term a WYSIWYM interface would be a great asset. Anybody up to the challenge? :) If we don't eat our own dog food, there are several commercial XML editors that provide a WYSIWYM interface. Some provide free-to-use versions but are closed source. However, one such editor is GPL(3): Syntext Serna Free (http://www.syntext.com/products/serna-free/). For professional reasons I intend to look at that tool. Serna Free is the only professional XML editor supporting DocBook I know that is free/libre. The sources are available online. Serna Free uses Qt4. :( Deb and rpm packages are available as well as a generic install script. Quanta Plus should be our first choice. We make do until Quanta Plus receives a WYSIWYM display like that provided for HTML. :) Quanta Plus provides some validation tools. Quanta Plus does not provide the full backend support that Syntext Serna Free provides, but we'll learn that backend processing support, which I discuss next. :) 2. Backend processing. Minimally, Docbook backend processing requires xmllint and xsltproc. The former to validate the code and the latter to convert to HTML and PDF. Both tools are available on all distros that TDE can run. Yet we do not have our own style sheets or DTD (Document Type Definition). A challenge with any generic default xslt backend support is the resulting documents are bland --- ugly and seldom flow correctly. For example, paragraph headings often get split across pages from the first paragraph. To produce professional documents requires serious hand tweaking of the xslt backend. I haven't done that but I want to learn. The OpenSuse folks use the Novell novdocx.dtd. The license is free/libre. Fortunately I found a copy of the Novell backend package containing the DTD and style sheets, XSLT scripts, etc. I haven't any idea yet how to install or use the tool chain, but I have them downloaded. Because the backend processing scripts are available in that package, with a learning curve we should be able to use them to produce both professional PDF and HTML documents and avoid the xslt tweaking process. :) Although I understand the principles of all that is involved, I never have used this tool chain. Maybe we can find an OpenSuse documentation team member who still has a soft spot for the KDE3 tradition and is willing to help us bootstrap our documentation project? Anybody using OpenSuse know such a person? :) 3. Content. I have copies of some excellent KDE3 user guides, which include the last OpenSuse KDE3 guides. I found and downloaded the DocBook sources for the OpenSuse 10.3 guides, which was the last guide to address KDE3. All of the guides I have are under free/libre licenses. We can use the content of those guides for a significant portion of our own user guides. I need to learn how to install those DocBook sources in a way to use Quanta Plus for editing. We will need to replace many of the screen grabs. We lack a style guide. Style guides provide guidance for formatting, syntax, etc. I see no reason to reinvent wheels here. The OpenSuse KDE3 guides are quite professional. I also have a copy of the KDE style guide and author's guide. All of that documentation is free/libre. We should adopt those style guides and DTD. I started an outline/table of contents for our guides. My initial effort will be to plug-and-chug existing content into that outline. Then replace screen grabs. Then edit and proofread, something I have been doing for years. After the Docbook files are ready, they can be uploaded to GIT. From then on anybody can make changes. Further, we should be able to adapt all of the backend scripting support so we can produce guides in real time. ==================== Summary ==================== I propose we use DocBook to maintain our user guide sources. We use the OpenSuse DTD and processing scripts. Familiarity with DocBook allows us to also start revising the Handbook help pages, which is much needed. We use the OpenSuse and KDE style guides. We use existing free/libre KDE3 user guides as a foundation for our guides. We provide full credit to all in our Credits section. Like the OpenSuse guides, I recommend we provide both a Quick Start Guide and a comprehensive user's guide. For community users who want to help with documentation, we design a KWord template with a set of style tags. We provide a how-to for using the template. We create some scripts to convert those documents to DocBook. I already have stated I am ready to be the grunt person to get our documentation started. Please add to this conversation! :) Darrell

13 years

Odd tdelibs build error

by Darrell Anderson

I just posted a tdelibs FTBFS error a few messages back. I decided to run the build again with NUMJOBS=-j1. This time I did not receive the same tdelfeditor errors. This time I received the following errors: ================================================= In file included from /dev/shm/tdelibs/dcop/dcopclient.cpp:2285: /dev/shm/tdelibs.build/dcop/dcopclient.moc:121: error: ISO C++ forbids declaration of 'QCString' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:121: error: expected ',' or '...' before '&' token /dev/shm/tdelibs.build/dcop/dcopclient.moc:121: error: prototype for 'void DCOPClient::applicationRegistered(int)' does not match any in class 'DCOPClient' /dev/shm/tdelibs/dcop/dcopclient.h:745: error: candidate is: void DCOPClient::applicationRegistered(const TQCString&) /dev/shm/tdelibs.build/dcop/dcopclient.moc:134: error: ISO C++ forbids declaration of 'QCString' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:134: error: expected ',' or '...' before '&' token /dev/shm/tdelibs.build/dcop/dcopclient.moc:134: error: prototype for 'void DCOPClient::applicationRemoved(int)' does not match any in class 'DCOPClient' /dev/shm/tdelibs/dcop/dcopclient.h:754: error: candidate is: void DCOPClient::applicationRemoved(const TQCString&) /dev/shm/tdelibs.build/dcop/dcopclient.moc:166: error: ISO C++ forbids declaration of 'QCString' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:166: error: expected ',' or '...' before '&' token /dev/shm/tdelibs.build/dcop/dcopclient.moc:166: error: prototype for 'void DCOPClient::callBack(int, int)' does not match any in class 'DCOPClient' /dev/shm/tdelibs/dcop/dcopclient.h:794: error: candidate is: void DCOPClient::callBack(int, const TQCString&, const TQByteArray&) /dev/shm/tdelibs.build/dcop/dcopclient.moc: In member function 'virtual bool DCOPClient::qt_emit(int, TQUObject*)': /dev/shm/tdelibs.build/dcop/dcopclient.moc:196: error: ISO C++ forbids declaration of 'type name' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:196: error: ISO C++ forbids declaration of 'type name' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:196: error: expected primary-expression before 'const' /dev/shm/tdelibs.build/dcop/dcopclient.moc:196: error: expected ')' before 'const' /dev/shm/tdelibs.build/dcop/dcopclient.moc:197: error: ISO C++ forbids declaration of 'type name' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:197: error: ISO C++ forbids declaration of 'type name' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:197: error: expected primary-expression before 'const' /dev/shm/tdelibs.build/dcop/dcopclient.moc:197: error: expected ')' before 'const' /dev/shm/tdelibs.build/dcop/dcopclient.moc:200: error: ISO C++ forbids declaration of 'type name' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:200: error: ISO C++ forbids declaration of 'type name' with no type /dev/shm/tdelibs.build/dcop/dcopclient.moc:200: error: expected primary-expression before 'const' /dev/shm/tdelibs.build/dcop/dcopclient.moc:200: error: expected ')' before 'const' make[2]: *** [dcop/CMakeFiles/DCOP-shared.dir/dcopclient.cpp.o] Error 1 make[2]: Leaving directory `/dev/shm/tdelibs.build' make[1]: *** [dcop/CMakeFiles/DCOP-shared.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/tdelibs.build' make: *** [all] Error 2 ================================================= tdelibs/dcop/dcopclient.cpp:2285: #include <dcopclient.moc> I don't know anything yet about moc files. Would somebody provide a short course while I'm looking through the web to learn more? I'm thinking the errors mean tqt3 and tqtinterface might not be building or installing correctly because there should not be any references to QString. They should be TQString. Both tqt3 and tqtinterface built without errors. Darrell

13 years

C++ Question

by Darrell Anderson

When a C++ (boolean) function contains multiple if-else tests, and each of those tests contains a return statement (return=false; or return=true;), does the function exit when encountering the first return? Or does the function continue executing the remaining code within that function? In other words, when encountering that first return, does the function exit much like a break command? Darrell

13 years

R14 Artwork.

by Calvin Morrison

Hello Everyone, For a while I have been pondering the cosmetic and artwork related changes we should try and work on for R14. Unlike most projects, we are rather nostalgic, so going flat out new won't work for us. A new default theme or such is not advisable. Users won't like it. I think we should instead focus on creating an improved R14 style. A theme consists of: Backgrounds, Color Schemes, Fonts, Icons, Window Decorations, Widget Styles, and Screensavers. These don't need drastic revision, instead they need careful changes to help reflect our goals. Speed simplicity and customization are my top priorities. What do we need to improve? My vote is this 1) New backgrounds - Our defaults are out of date and I don't really like them, Every new release should see some fresh artwork. Users can keep the old one if the prefer it. These need to be pleasant to view and also look modern. (not to glossy though). 2) Improved Window Decorations - I am not a fan of plastic. I am a fan of the KDE2 window decoration. Either way we should set about making sure the default on is in tip top shape and has max configuration. Should we keep plastic as our default deco? 3) Icons - I think we are OK with these. Some icons may need to be looked over in our crystal svg set. I want to maximize visual efficiency of our icons. Some may be unclear or hard to see at different sizes. This should be lo 4) Styles - I would like to see Plastik expanded by including more options, especially to remove stippled drawing on the tabs. any thoughts? I think we should start thinking about this now, since this release will be mostly bug fixes, changes like this could also be slipped in. Calvin Morrison

13 years

tqt-mt.pc

by Darrell Anderson

When I build tqt3 from GIT, the pkgconfig file gets built and installed to: /opt/trinity/lib/tqt3-R14.0.0/lib/pkgconfig/tqt-mt.pc rather than /opt/trinity/lib/pkgconfig/tqt-mt.pc Bug? Darrell

13 years

tdelibs FTBFS: (/bin/sh: ./tdelfeditor: No such file or directory)

by Darrell Anderson

I'm trying to build tdelibs from GIT. The build fails and I always receive this error message: /bin/sh: ./tdelfeditor: No such file or directory I have -DWITH_ELFICON=OFF. I also tried removing that option because the option defaults to OFF from -DWITH_ALL_OPTIONS. According to CMakeLists.txt, the tdelfeditor subdirectory should not get built. All dependency packages build and install without error. Darrell

13 years

elficon support was requested, but libr was not found on your system

by Darrell Anderson

Which package is cmake looking for? "libr" is vague. I get that message when I enable -DWITH_ELFICON=ON. Darrell

13 years

Building Trinity GIT dependencies

by Darrell Anderson

Is sip4-tqt a full package to replace the distro package or a layer package like tdegraphics poppler-tqt? Is libarts-gpl a full package to replace the distro package or a layer package? Where is tqca? Has that package been combined with tqca-tls? When is tqscintilla required? Darrell

13 years

tdeversion.h

by Darrell Anderson

In GIT, tdeversion.h, TDE_VERSION_STRING = R14.0.0. In 3.5.13, KDE_VERSION_STRING = 3.5.13. There was no prefix "R." Do we want that "R" prefix in the string? I ask because I use that string in my package naming. I'm getting up to speed with building from GIT and noticed the difference. Just asking. Yay or Nay is fine. :) Darrell

13 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels