Re: Your Subject

hey please ignore the previous email i was testing something and this turned into spam sorry On Tue, Jan 2, 2024 at 4:31 PM wrote: > Hello, will get back soon.

[no subject]

Hey guys, I'm a second year engineering student interested in GSOC '21. I've gone through https://community.kde.org/GSoC/2021/Ideas and have zeroed in on an app I like and know a little about (Okular). I plan to get myself familiarized with it more over next few days and then try to get my hands

[no subject]

Hello , how can I apply in projects  with KDE ,Its first time to me in GSOC and I  need help to write proposal .  Sent from Mail for Windows 10 

Re: (No Subject)

I'm now in contact with Anuj  Carl \ Original Message On 4 Dec 2019, 08:45, Anuj Bansal < bansalan...@gmail.com> wrote: > > > > Hello Everyone! > > I am an aspiring web developer and I would like to participate in Season of > KDE. Can anyone guide me to any Web Development

[no subject]

Hello Everyone! I am an aspiring web developer and I would like to participate in Season of KDE. Can anyone guide me to any Web Development projects I can work on?

[no subject]

Hello my name is pahonsi bebeto Achile new developer on c++ programing language that want get more experience by participate in to Google summer of 2019 And for that I need mentor and help .and where can I started. Thanks you

D15556: Fix: Email highlighting for unclosed parenthesis in Subject header

This revision was automatically updated to reflect the committed changes. Closed by commit R216:b1da54ab91e3: Fix: Email highlighting for unclosed parenthesis in Subject header (authored by dhaumann). REPOSITORY R216 Syntax Highlighting CHANGES SINCE LAST UPDATE https://phabricator.kde.org

D15556: Fix: Email highlighting for unclosed parenthesis in Subject header

vkrause accepted this revision. This revision is now accepted and ready to land. REPOSITORY R216 Syntax Highlighting BRANCH fix-email-subject (branched from master) REVISION DETAIL https://phabricator.kde.org/D15556 To: dhaumann, vkrause Cc: kwrite-devel, kde-frameworks-devel, michaelh

D15556: Fix: Email highlighting for unclosed parenthesis in Subject header

dhaumann created this revision. dhaumann added a reviewer: vkrause. Herald added projects: Kate, Frameworks. Herald added subscribers: kde-frameworks-devel, kwrite-devel. dhaumann requested review of this revision. REVISION SUMMARY Unfortunately, the "Subject:" header needs to

[no subject]

--- Begin Message --- jtamate created this revision. jtamate added reviewers: dfaure, Frameworks. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: kde-frameworks-devel. jtamate requested review of this revision. REVISION SUMMARY Don't restore user

Re: Differential e-mail subject re-arrangement

Hi Ben. Thanks for your fixes, much appreciated. On jeudi 2 mars 2017 09:08:25 CET Ben Cooksley wrote: > We'd need a strong use case to explain to upstream why repository > should be in the Subject, IMHO the use case *is* strong. If you watch many repositories (as we do on thi

Re: Differential e-mail subject re-arrangement

On Fri, Mar 3, 2017 at 10:41 AM, Jan Kundrát wrote: > On čtvrtek 2. března 2017 9:08:25 CET, Ben Cooksley wrote: >> >> In regards to the way email subjects are treated, I've now customised >> the metamta.differential.subject-prefix preference on our installation >> to be blank, to

Re: Differential e-mail subject re-arrangement

On čtvrtek 2. března 2017 9:08:25 CET, Ben Cooksley wrote: In regards to the way email subjects are treated, I've now customised the metamta.differential.subject-prefix preference on our installation to be blank, to the "[Differential]" part should no longer be present. Roughly at the time you

Re: Differential e-mail subject re-arrangement

tial' part of it to just 'Diff'. >>> > >>> > Agreed to both. >>> >>> +1 >> >> Yes, totally, and I would even like the repo name to be added... >> >> But >> >> https://secure.phabricator.com/D9342 "Make Different

Re: Differential e-mail subject re-arrangement

tial emails start makes it much easier to >> > > > read.> >> > > >> > > +1 I'd even shorten The 'Differential' part of it to just 'Diff'. >> > >> > Agreed to both. >> >> +1 > > Yes, totally, and I would even like the repo

Re: Differential e-mail subject re-arrangement

even shorten The 'Differential' part of it to just 'Diff'. > > > > Agreed to both. > > +1 Yes, totally, and I would even like the repo name to be added... But https://secure.phabricator.com/D9342 "Make Differential email subject more configurable.", ABANDONED.

Re: Differential e-mail subject re-arrangement

On Tuesday, 28 February 2017 21:31:44 CET Michael Pyne wrote: > On Tue, Feb 28, 2017 at 08:38:12PM +0100, Ivan Čukić wrote: > > > [Differential] D4508: Plasma controls based on QtQuickControls2 > > > [Commented On]> > > > > I personally find that having a "vertical" line in which all the > >

Re: Differential e-mail subject re-arrangement

On Tue, Feb 28, 2017 at 08:38:12PM +0100, Ivan Čukić wrote: > > [Differential] D4508: Plasma controls based on QtQuickControls2 > > [Commented On] > > > > I personally find that having a "vertical" line in which all the subjects > > of the differential emails start makes it much easier to

Re: Differential e-mail subject re-arrangement

> [Differential] D4508: Plasma controls based on QtQuickControls2 [Commented > On] > > I personally find that having a "vertical" line in which all the subjects of > the differential emails start makes it much easier to read. +1 I'd even shorten The 'Differential' part of it to just 'Diff'.

Differential e-mail subject re-arrangement

What do you think about rearranging the subject to move the [Commented On] [Changed Subscribers] [Accepted] [Updated, 2,978 lines] etc from the beginning to the end, i.e. [Differential] [Updated, 2,978 lines] D4508: Plasma controls based on QtQuickControls2 [Differential] [Commented

[no subject]

Hi, I am new here. I wanted to contribute. So, can you guide me what to do to get started? Thanks.

Re: Review Request 127023: [KFileMetadata] Support Origin Email subject/sender/id

> On Aug. 10, 2016, 4:52 nachm., Kevin Funk wrote: > > I'm late to the party, but ...: This won't fly on Windows (at least under > > MSVC). I'm not usually compiling kfilemetadata.git on Windows, so I wasn't > > affected by this change thus didn't notice. > > > > Can we make the dependency on

Re: Review Request 127023: [KFileMetadata] Support Origin Email subject/sender/id

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127023/#review98302 --- I'm late to the party, but ...: This won't fly on Windows

Re: Review Request 127023: [KFileMetadata] Support Origin Email subject/sender/id

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127023/ --- (Updated Feb. 26, 2016, 8:56 p.m.) Status -- This change has been

Re: Review Request 127023: [KFileMetadata] Support Origin Email subject/sender/id

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127023/#review92404 --- Fix it, then Ship it! src/propertyinfo.cpp (line 421)

Review Request 127023: [KFileMetadata] Support Origin Email subject/sender/id

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127023/ --- Review request for KDE Frameworks, KDEPIM, Daniel Vrátil, Sebastian

[no subject]

Are we interested in making an application? Late days, but perhaps some teams have something suitable? VALS Semester of Code 2nd round is open for new organizations until Jan 13th. This is the new site: http://vps2.semesterofcode.com/ This is the old instructions:

[no subject]

Dear all, I would like to know more about KHTML rendering engine project of KDE. We are in search of a suitable rendering engine to be ported to an older version of QNX. that is, QNX4.25. KHTML seems interesting as it is open-source and its wikipedia link says it is cross-platform. That makes us

git repo name in review request e-mail subject

Hey all, In looking at frameworks e-mail each day I find it would be much simpler if we would all add the git repo we are submitting the review request for in the subject. e-mail with subjects like make documentation match new values in code (not trying to single this one out, many

Re: git repo name in review request e-mail subject

Christoph Feck ha scritto: On Wednesday 30 April 2014 22:55:55 Jeremy Whiting wrote: In looking at frameworks e-mail each day I find it would be much simpler if we would all add the git repo we are submitting the review request for in the subject. If you have added yourself as a maintainer

Re: git repo name in review request e-mail subject

On Wed, April 30, 2014 14:55:55 Jeremy Whiting wrote: Hey all, In looking at frameworks e-mail each day I find it would be much simpler if we would all add the git repo we are submitting the review request for in the subject. e-mail with subjects like make documentation match new values

Re: git repo name in review request e-mail subject

we are submitting the review request for in the subject. If you have added yourself as a maintainer of a repository via TARGET_PEOPLE in its .reviewboardrc file, then you are mailed directly, while the other review request simply go to the list. Unfortunately, this doesn't always seem to work

Re: git repo name in review request e-mail subject

On Wed, Apr 30, 2014 at 6:08 PM, Michael Pyne mp...@kde.org wrote: On Wed, April 30, 2014 14:55:55 Jeremy Whiting wrote: Hey all, In looking at frameworks e-mail each day I find it would be much simpler if we would all add the git repo we are submitting the review request for in the subject

Re: Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

On Monday, March 31, 2014 23:24:09 Albert Astals Cid wrote: El Dilluns, 31 de març de 2014, a les 22:34:21, Dominik Haumann va escriure: On Monday 31 March 2014 17:27:33 Ben Cooksley wrote: On Mon, Mar 31, 2014 at 5:38 AM, Gregor Mi codeminis...@publicstatic.de Ok. Any idea about the

Re: Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

On Tue, Apr 1, 2014 at 9:23 PM, Dominik Haumann dhaum...@kde.org wrote: On Monday, March 31, 2014 23:24:09 Albert Astals Cid wrote: El Dilluns, 31 de març de 2014, a les 22:34:21, Dominik Haumann va escriure: On Monday 31 March 2014 17:27:33 Ben Cooksley wrote: On Mon, Mar 31, 2014 at 5:38

Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

On Tue, Apr 1, 2014 at 9:23 PM, Dominik Haumann dhaum...@kde.org wrote: On Monday, March 31, 2014 23:24:09 Albert Astals Cid wrote: El Dilluns, 31 de març de 2014, a les 22:34:21, Dominik Haumann va escriure: On Monday 31 March 2014 17:27:33 Ben Cooksley wrote: On Mon, Mar 31, 2014

Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

I've no idea if this will actually end up the case, but won't KF 5.1 end up depending on Qt 5.3? ie. this problem is going to come up again once KF 5.0 is released. Looking at the qt list, it might be, that they reconsider to merge all gits into one again which will make tracking easy

Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

On Monday 31 March 2014 17:27:33 Ben Cooksley wrote: On Mon, Mar 31, 2014 at 5:38 AM, Gregor Mi codeminis...@publicstatic.de wrote: On 30/03/14 12:41, Aleix Pol wrote: On Sun, Mar 30, 2014 at 12:02 PM, Gregor Mi codeminis...@publicstatic.de mailto:codeminis...@publicstatic.de wrote:

Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

On Tue, Apr 1, 2014 at 9:34 AM, Dominik Haumann dhaum...@kde.org wrote: On Monday 31 March 2014 17:27:33 Ben Cooksley wrote: On Mon, Mar 31, 2014 at 5:38 AM, Gregor Mi codeminis...@publicstatic.de wrote: On 30/03/14 12:41, Aleix Pol wrote: On Sun, Mar 30, 2014 at 12:02 PM, Gregor Mi

Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

El Dilluns, 31 de març de 2014, a les 22:34:21, Dominik Haumann va escriure: On Monday 31 March 2014 17:27:33 Ben Cooksley wrote: On Mon, Mar 31, 2014 at 5:38 AM, Gregor Mi codeminis...@publicstatic.de wrote: On 30/03/14 12:41, Aleix Pol wrote: On Sun, Mar 30, 2014 at 12:02 PM, Gregor

Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

On 30/03/14 12:41, Aleix Pol wrote: On Sun, Mar 30, 2014 at 12:02 PM, Gregor Mi codeminis...@publicstatic.de mailto:codeminis...@publicstatic.de wrote: On 30/03/14 11:29, Gregor Mi wrote: Hi, has anyone recently build qt5 from scratch as described here [1]?

Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

On Sun, Mar 30, 2014 at 6:38 PM, Gregor Mi codeminis...@publicstatic.dewrote: On 30/03/14 12:41, Aleix Pol wrote: On Sun, Mar 30, 2014 at 12:02 PM, Gregor Mi codeminis...@publicstatic.de mailto:codeminis...@publicstatic.de wrote: On 30/03/14 11:29, Gregor Mi wrote: Hi,

Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)

On Mon, Mar 31, 2014 at 5:38 AM, Gregor Mi codeminis...@publicstatic.de wrote: On 30/03/14 12:41, Aleix Pol wrote: On Sun, Mar 30, 2014 at 12:02 PM, Gregor Mi codeminis...@publicstatic.de mailto:codeminis...@publicstatic.de wrote: On 30/03/14 11:29, Gregor Mi wrote: Hi,

[no subject]

Hi I am learning Qt and I wanted to start building okular on qt and solve some bugs. I have downloaded the repository but it contains a huge amount of files which I am finding very hard to understand . If anyone could guide me to understand the structure of the code so that I could start

[no subject]

Hi I wanted to ask that how should I use the Okular repository code to start building the application ie. understanding the code structure of Okular Gaurav Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe

[no subject]

Hi, I am a novice in the field of contributing to open source software. Regarding skills, I do have some knowledge of programming and I am willing to make contribution to an open source project or application.If someone can direct me to an ongoing project which needs contribution, I would be

[no subject]

hello, i am intrested in your project localization team management tool and want to contribute to open source software. regards Abhishek Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe

[no subject]

hi kde im interested in gsoc -2012 Social music - Tomahawk features in Amarok im doing my undergrad(2nd yr) . i really want to grow as a programmer and i  believe that the project and gsoc can help me with that Considering i made a music player (using trend mapping, . net and a dbms ) i was

[no subject]

set authenticate IXO13IqM set delivery off

[no subject]

Hi, I am Aman (irc : dedman) , a student of computer science from India. I love KDE Software and have been using it for over a year. I especially love using Amarok, Kate, Kopete, KMail and the Plasma Desktop as a whole. I wish to contribute to KDE but I have no prior experience with contributing

[no subject]

previous to the commit with subject Merged very early alpha-version of Dolphin 2.0 where was comitted the start of this development path. My 2 cents,Silouck Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe

Re: Usefulness of Subject-header of git commit mails

first sentence turns out to be a good summary. I think it's just to emphasise that the first line is actually a summary (or title or subject or whatever) and not *just* the first line of a multi-line message. The first line should be able to stand on its own and the blank line helps to make

Re: Usefulness of Subject-header of git commit mails

On Sunday 23 January 2011, Milian Wolff wrote: But probably my problem is that I only work on semi-large repositories like KDevelop/KDevplatform/Kate. There I'm interested in *everything* that goes on. In Calligra you have only one big repo for all the apps, correct? Here I indeed can

Re: Usefulness of Subject-header of git commit mails

Example: [KDevPlatform] fafd165: Don't completely ignore the retrieved top-context For me, this is more useful, so +1 Maybe adding a keyword 'commit' before the short hash like this [KDevPlatform] Commit fafd165: Don't completely ignore the retrieved top-context -- Cheerio, Ivan -- While

Re: Usefulness of Subject-header of git commit mails

Boudewijn Rempt, 23.01.2011: On Sunday 23 January 2011, Milian Wolff wrote: Hey all, I've brought this discussion to the sysadmins recently and they asked me to ask for feedback here. So there it goes: Recently, the format of the subject of git commit emails was adapted to use

Re: Usefulness of Subject-header of git commit mails

On 1/23/2011 9:30 PM, Milian Wolff wrote: What was broken? Nothing as far as Commitfilter is concerned. Commitfilter actually acts on the X-Commit-Directories headers, not the mail subject. This header was actually somewhat broken in the old mails, it has been fixed now as part of the hooks

Re: Usefulness of Subject-header of git commit mails

Eike Hein, 23.01.2011: On 1/23/2011 9:30 PM, Milian Wolff wrote: What was broken? Nothing as far as Commitfilter is concerned. Commitfilter actually acts on the X-Commit-Directories headers, not the mail subject. This header was actually somewhat broken in the old mails, it has been fixed

Re: Usefulness of Subject-header of git commit mails

: commit subject * branch only shown if != master. If we could agree on a hybrid, IMHO that'd be a better solution than having different formats in play. It's technically possible to make it configurable, but people who subscribe to multiple repositories with different formats might get irked

Re: Usefulness of Subject-header of git commit mails

*] common root path: commit subject * branch only shown if != master. If we could agree on a hybrid, IMHO that'd be a better solution than having different formats in play. It's technically possible to make it configurable, but people who subscribe to multiple repositories with different

Re: Usefulness of Subject-header of git commit mails

- Oorspronkelijk bericht - On 1/23/2011 9:30 PM, Milian Wolff wrote: What was broken? Nothing as far as Commitfilter is concerned. Commitfilter actually acts on the X-Commit-Directories headers, not the mail subject. This header was actually somewhat broken in the old mails, it has