feat: add Konsole recipe source and patches
This commit is contained in:
@@ -0,0 +1,52 @@
|
||||
|
||||
Items for the Konsole maintainer:
|
||||
=================================
|
||||
|
||||
A new maintainer may need super powers for some of these. If so, put in a
|
||||
request.
|
||||
https://go.kde.org/systickets
|
||||
|
||||
A. New releases
|
||||
1. Update src/main.cpp for version (2.7, 2.7.1, etc)
|
||||
a. Typically, Konsole is 2 versions behind KDE (KDE 4.7, Konsole 2.7)
|
||||
b. If no changes are made, don't increase version.
|
||||
2. Verify KDE bug site has all versions
|
||||
a. When a new x.y release is coming out, create the x.y and all x.y.z
|
||||
Example: 2.8, 2.8.1, 2.8.2, 2.8.3, 2.8.4, 2.8.5
|
||||
b. https://bugs.kde.org/editversions.cgi?product=konsole
|
||||
At the bottom there is an 'Add' link
|
||||
3. Once a x.y release comes out, in git master change version to x.y+1.999
|
||||
and add that to the Konsole BKO version.
|
||||
Example, 4.7 has been branched and git master is open again, change
|
||||
version to 4.7.999 in master.
|
||||
4. Usually the KDE release team handles the git tagging
|
||||
|
||||
B. Handbook
|
||||
1. For x.y release try to keep handbook up to date.
|
||||
2. Handbook is the index.docbook in konsole/doc/manual/
|
||||
|
||||
C. Sites
|
||||
1. konsole.kde.org is the only site the maintainer is responsible.
|
||||
a. It is currently in git (2012).
|
||||
https://projects.kde.org/projects/websites/konsole-kde-org
|
||||
b. If it becomes to much work or outdated, it might be forwarded to
|
||||
https://userbase.kde.org/Konsole
|
||||
|
||||
D. Mailing list
|
||||
1. https://mail.kde.org/mailman/admin/konsole-devel
|
||||
Password is given from previous maintainer (or someone who knows it).
|
||||
Robert Knight or Kurt Hindenburg
|
||||
2. As of 2013, all new subscriptions and first post require admin
|
||||
approval. This was done to cut down on spam on the list. These
|
||||
options can be changed on the link in #1
|
||||
|
||||
Links
|
||||
1. General Konsole bug page:
|
||||
https://bugs.kde.org/editproducts.cgi?action=edit&product=konsole
|
||||
2. An attempt to get more interest in Konsole
|
||||
https://userbase.kde.org/KonsoleDevelopment
|
||||
3. HTML version of Handbook
|
||||
https://docs.kde.org/?application=konsole
|
||||
4. KDE schedule https://community.kde.org/Schedules
|
||||
|
||||
|
||||
@@ -0,0 +1,133 @@
|
||||
Developer Documentation for Konsole
|
||||
|
||||
NOTE: this document is from 2007; a lot has changed. Please ask on the
|
||||
Konsole mailing list if you need any guidance.
|
||||
|
||||
Authors: Robert Knight < robertknight@gmail.com >
|
||||
Last Updated: 7th May 2007
|
||||
Summary: Introduction to Konsole developer documentation
|
||||
===============================================================
|
||||
|
||||
Contents:
|
||||
|
||||
1. Introduction
|
||||
2. Documentation format
|
||||
3. Documentation layout (aka. 'Where to find things')
|
||||
4. Contributing to Konsole
|
||||
4.1 Discussion and help
|
||||
4.2 Submitting code
|
||||
4.2.1 API documentation guidelines
|
||||
4.2.2 Code style guidelines
|
||||
|
||||
===============================================================
|
||||
|
||||
1. Introduction
|
||||
|
||||
This document explains the layout of the developer documentation folder,
|
||||
and basic guidelines for contributors.
|
||||
|
||||
2. Documentation format
|
||||
|
||||
To try and make it easier for developers to find the information they need
|
||||
about Konsole, the use of a standard document template which answers the following
|
||||
questions is encouraged:
|
||||
|
||||
- What is this document?
|
||||
- Who wrote it?
|
||||
- When was it last updated?
|
||||
- What is it about?
|
||||
- Where can I find information about <subject> within this document?
|
||||
|
||||
The current template can be found in design/developer-documentation-template
|
||||
|
||||
There is older documentation in the old-documents/ folder which does
|
||||
not follow this format. This is kept as a reference. Assistance
|
||||
in tidying up documentation from that directory by using the documentation
|
||||
template would be appreciated.
|
||||
|
||||
3. Documentation layout
|
||||
|
||||
DELETED design/ - Documentation about the design of Konsole, and templates
|
||||
for developer documentation.
|
||||
DELETED design/historic - Documentation which was prepared during the KDE 4.0x development
|
||||
cycle but which is no longer relevant.
|
||||
|
||||
DELETED research/ - Results of research into user's experiences with Konsole
|
||||
|
||||
DELETED user-interface/ - Documentation concerning design and analysis of the user interface.
|
||||
|
||||
DELETED old-documents/ - An assortment of documentation which was created during earlier
|
||||
releases of Konsole. There is useful information here, particularly
|
||||
about the type of terminal which Konsole emulates, but it is not
|
||||
organised.
|
||||
|
||||
4. Contributing to Konsole
|
||||
|
||||
Help with Konsole's development, whether it involves code, user interface suggestions or
|
||||
other resources is greatly appreciated.
|
||||
|
||||
4.1 Discussion and help
|
||||
|
||||
Discussion about Konsole development takes place primarily on the Konsole mailing list,
|
||||
at konsole-devel@kde.org. If you need help with Konsole development or wish to discuss
|
||||
implementation of a feature, fixes to bugs etc., then this is an appropriate place to
|
||||
do that.
|
||||
|
||||
4.2 Submitting code
|
||||
|
||||
Patches can be submitted for Konsole in a number of places:
|
||||
|
||||
- For bugfixes, we recommend that you attach the patch to the relevant bug report on bugs.kde.org
|
||||
- For new features, a patch can be attached to a relevant wishlist report on bugs.kde.org if
|
||||
there is one, and/or submitted to konsole-devel@kde.org
|
||||
|
||||
If your patch adds new methods or classes then please ensure that there is API documentation for
|
||||
them in the code. Looking at the header files for existing classes should give you an idea of
|
||||
what is asked for.
|
||||
|
||||
|
||||
4.2.1 API documentation guidelines
|
||||
|
||||
Good API documentation in the code is very helpful for other developers. Here are a few guidelines on
|
||||
writing API documentation for Konsole:
|
||||
|
||||
- All classes should have documentation which describes the basic function of the class.
|
||||
Usage examples are appreciated.
|
||||
- All public and protected methods should have API documentation which describes what
|
||||
the method does and what the returned value (if any) means.
|
||||
Parameter documentation is encouraged if the method has more than a couple of parameters
|
||||
or if the use of a parameter is not immediately clear from its name and type.
|
||||
- All public and protected enumerations and constants should have API documentation which
|
||||
describes what the various values mean.
|
||||
- The usage of brief standard comments next to private methods is encouraged to
|
||||
provide a quick explanation of what that method does.
|
||||
|
||||
4.2.2 Code style guidelines
|
||||
|
||||
The API style roughly follows that used in the Qt and KDE classes.
|
||||
|
||||
There are no strict guidelines on aspects of the code such as indentation, braces
|
||||
or spacing, although following the style of the existing code is a good idea.
|
||||
|
||||
Below is a list of the most important style considerations which have been developed
|
||||
following experience working on earlier Konsole code:
|
||||
|
||||
- Variables and methods should have CLEAR, verbose names. The use of abbreviations
|
||||
should be avoided except for very common cases.
|
||||
|
||||
- The use of named constants is preferred over literals for clarity, and also to prevent
|
||||
the need to edit each instance of a literal if the value needs to be changed.
|
||||
|
||||
- The use of macros ( #define ) should be avoided where possible. enums, inline methods
|
||||
templates, static constants etc. are strongly preferred.
|
||||
- Inside classes, private member fields have an underscore prefix ( eg. _myPrivateField )
|
||||
- Private slots in classes DO NOT have a "slot" prefix before their name which is often
|
||||
seen in other KDE applications.
|
||||
|
||||
Earlier Konsole code had a proliferation of two-letter variable names, which made it hard
|
||||
to read and understand in some places, and let directly to bugs in others. Descriptive naming
|
||||
and sensible use of comments are strongly encouraged in new code.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# Add this to your .gitconfig after renaming/moving/etc
|
||||
#[commit]
|
||||
# template = ~/.commit-template
|
||||
#
|
||||
# Please enter the commit message for your changes. Lines starting
|
||||
# with '#' will be ignored, and an empty message aborts the commit.
|
||||
# You MUST wrap all lines at 72 characters.
|
||||
# https://community.kde.org/Policies/Commit_Policy
|
||||
# https://community.kde.org/Infrastructure/GitLab#Write_a_good_commit_message
|
||||
# For Git commit hook keywords see:
|
||||
# https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages
|
||||
# ==[ Subject: One line ONLY short meaningful description for logs ]===|
|
||||
|
||||
# ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=====|
|
||||
|
||||
# ==[ Details: Describe what changed and explain why it changed]=======|
|
||||
|
||||
|
||||
# ==[ Fields: Uncomment and edit where applicable ]====================|
|
||||
# --[ Close bug in bugs.kde.org as fixed ]-----------------------------|
|
||||
#BUG: <bug number>
|
||||
#FIXED-IN: <optional release version>
|
||||
# --[ Add to release changelog optionally close wish in bugs.kde.org ]-|
|
||||
#FEATURE: <optional bug number>
|
||||
#FIXED-IN: <optional release version>
|
||||
# --[ Copy commit message to a bug or wish in bugs.kde.org ]-----------|
|
||||
#CCBUG: <bug number>
|
||||
# --[ Copy commit message to an email address ]------------------------|
|
||||
#CCMAIL: <email>
|
||||
#
|
||||
# --[ Notify documentation team of user visible changes ]--------------|
|
||||
#GUI:
|
||||
#
|
||||
# --[ Notify team of something interesting ]-------------|
|
||||
#CHANGELOG:
|
||||
#
|
||||
# --[ Mark commit as silent for commit filter filtering. ]-------------|
|
||||
# [ Use sparingly and only for uninteresting and ]
|
||||
# [ uncontroversial commits. ]
|
||||
#GIT_SILENT
|
||||
#
|
||||
|
||||
+97
@@ -0,0 +1,97 @@
|
||||
#!/bin/bash
|
||||
# Add this to your konsole/.git/hooks/ folder to prevent push if message is not following commit-template
|
||||
# In your konsole folder type:
|
||||
# cp ./doc/developer/pre-push ./.git/hooks/pre-push && chmod +x ./.git/hooks/pre-push
|
||||
|
||||
# Get the current branch and apply it to a variable
|
||||
currentbranch=`git branch | grep \* | cut -d ' ' -f2`
|
||||
|
||||
# Gets the commits for the current branch and outputs to file
|
||||
git log $currentbranch --pretty=format:"%H" --not master > shafile.txt
|
||||
|
||||
if [ ! -f "./shafile.txt" ]
|
||||
then
|
||||
echo "It is not possible to write temporary files"
|
||||
echo "Check Read/Write permissions or remove this"
|
||||
echo "pre-push check"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if [ ! -s "./shafile.txt" ]
|
||||
then
|
||||
# if size is 0 there is no commit
|
||||
rm shafile.txt >/dev/null 2>&1
|
||||
exit 0
|
||||
fi
|
||||
|
||||
echo '
|
||||
====================
|
||||
Commit Message Check
|
||||
====================
|
||||
'
|
||||
|
||||
#colors used here
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
NC='\033[0m'
|
||||
|
||||
passedall=0
|
||||
# loops through the file an gets the messages
|
||||
for i in `cat ./shafile.txt`;
|
||||
do
|
||||
passed=0
|
||||
# gets the git commit message based on the sha
|
||||
git log --format=%B -n 1 "$i" > logfile.txt
|
||||
# load this message to an array
|
||||
mapfile -t gitmessage < ./logfile.txt
|
||||
|
||||
# commit title
|
||||
echo "- ${gitmessage[0]}"
|
||||
|
||||
# analise each line
|
||||
for (( nline=0; nline<${#gitmessage[@]}+1; nline++ ));
|
||||
do
|
||||
line=${gitmessage[$nline]}
|
||||
if [ ${#line} -gt 72 ]
|
||||
then
|
||||
echo -e " ${RED}*${NC} You MUST wrap all lines at 72 characters."
|
||||
passed=1
|
||||
fi
|
||||
|
||||
if [[ $nline -eq 1 && ${#line} -gt 0 ]]
|
||||
then
|
||||
echo -e " ${RED}*${NC} Follow the Subject with a blank line."
|
||||
passed=1
|
||||
fi
|
||||
|
||||
messagecheck=`echo $line | grep -w "BUG\|FEATURE\|FIXED-IN\|CCBUG\|CCMAIL\|GUI\|CHANGELOG"`
|
||||
if [ -n "$messagecheck" ]
|
||||
then
|
||||
messagecheck=`echo $line | grep ': '`
|
||||
if [ -z "$messagecheck" ]
|
||||
then
|
||||
echo -e " ${RED}*${NC} Your commit message has a formatting error."
|
||||
echo " Type ' ' after field specification"
|
||||
echo " -> $line"
|
||||
passed=1
|
||||
fi
|
||||
fi
|
||||
done
|
||||
|
||||
# Check if all passed
|
||||
if [ $passed -gt 0 ]
|
||||
then
|
||||
echo -e " Commit message ${RED}FAILED${NC}"
|
||||
passedall=1
|
||||
else
|
||||
echo -e " Commit message ${GREEN}PASSED${NC}"
|
||||
fi
|
||||
echo ""
|
||||
done
|
||||
# remove temporary files
|
||||
rm shafile.txt >/dev/null 2>&1
|
||||
rm logfile.txt >/dev/null 2>&1
|
||||
# Test mode remove the next '#' to test it
|
||||
#exit 1
|
||||
# If all passed in the check it will exit 0
|
||||
exit $passedall
|
||||
Reference in New Issue
Block a user