headers
Lydia Pintscher | 19 Aug 2010 22:58
Picon
Favicon
Gravatar

Re: : mentors needed

On Thu, Aug 19, 2010 at 22:51, Anne <annmam <at> gmail.com> wrote:
> Can we propose something like the Kids framework (a program where young kids apps would be run from)? Or a
light Kvtml editor?

Sure :)

> What sort of level and timeframe does the project need?

According to the program manager: a chunk of work that's suitable for
a group of 5-10 upper-year computer science students to work on for a
semester.
http://ucosp.ca/for-open-source/ also has a bit of info.

Cheers
Lydia

--

-- 
Lydia Pintscher
Amarok community manager
kde.org - amarok.kde.org - kubuntu.org
claimid.com/nightrose
Permalink | Reply | 2 comments |
headers
Anne | 19 Aug 2010 22:51
Picon

Re: : mentors needed

Can we propose something like the Kids framework (a program where young kids apps would be run from)? Or a
light Kvtml editor?
What sort of level and timeframe does the project need?

Anne-Marie 

Le 19 août 2010 à 18:51, Lydia Pintscher <lydia <at> kde.org> a écrit :

> Ideas are being collected at http://community.kde.org/UCOSP/2010/Ideas
> in the next two days now. Please add and ask me if you have any
> questions. Keep in mind that you need someone from your team to go to
> Toronto to the sprint.
> 
> 
> Cheers
> Lydia
> 
> -- 
> Lydia Pintscher
> Amarok community manager
> kde.org - amarok.kde.org - kubuntu.org
> claimid.com/nightrose
> _______________________________________________
> kde-edu mailing list
> kde-edu <at> mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu
_______________________________________________
kde-edu mailing list
kde-edu <at> mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
(Continue reading)

Permalink | Reply | 4 comments |
headers
Miha Cancula | 22 Aug 2010 16:03
Picon
Gravatar

: Review Request: Syntax Hightlighting in Cantor

This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5079/

Review request for KDE-Edu and Alexander Rieder.
By Miha Cancula.

Description

As discussed on email, I implemented a different approach to highlighting in Cantor. I'd like some feedback before committing it. I introduced additional API in DefaultHighlighter and moved most of the logic in it, so the individual backend-specific highlighters only specify conditions (either QString or QRegExp) and matching text formats. The code looks much cleaner this way. As Alexander and Oleksiy already determined, breaking the text into words and looking for these words is faster than iterating over a huge list of regexes and looking for each of them in the text. That's why functions, variables and keywords are implemented this way. OTOH, thing like comments and strings are easier done using Regexes, so this functionality is still there. The implementation uses a QHash<QString, QTextCharFormat> and a QHash<QRegExp, QTextCharFormat>. If anyone knows of a way to make it faster, please say so. I also updated highlighters for Octave, Maxima and Sage to use the word-based API as much as possible. Most of their code was also removed, because it's now in DefaultHighlighter. I left R alone because Oleksiy's work is not yet in trunk.

Testing

I tested Maxima and Sage and they seem to be faster than before for large blocks. I used to have problems with non-smooth scrolling in Octave due to the large number of functions, but now it feels normal. I didn't notice any regressions (yet). It all works both on trunk and 4.4.

Diffs

  • /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.h (1165930)
  • /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.cpp (1165930)
  • /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.h (1165930)
  • /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.cpp (1165930)
  • /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.h (1165930)
  • /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.cpp (1165930)
  • /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.h (1165930)
  • /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.cpp (1165930)

View Diff

 
_______________________________________________
kde-edu mailing list
kde-edu <at> mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
Permalink | Reply | 14 comments |
headers
Alexander Rieder | 23 Aug 2010 22:06
Picon

Re: : Review Request: Syntax Hightlighting in Cantor

This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5079/

On August 22nd, 2010, 8:15 p.m., Alexander Rieder wrote:

Hi, i haven't looked at the code yet, but in its current form the patch doesn't compile, as you try to include the non-existent "dbhighlighter.h" in octavehighlighter.h and sagehighlighter.h, and "highlightdatabase.h" in octavebackend.cpp.

On August 23rd, 2010, 6:17 p.m., Miha Cancula wrote:

I fixed the wrong includes, and I think the correct patch is up now.
Hi, (i haven't tried the new patch, is it any different except for the includes?) some initial comments: - Octave Highlighter: operators, keywords variables are members but don't have m_ prefix. On purpose? - Sage Highlighter needs newline at end of file - use kDebug instead of qDebug (in DBHighlighter.cpp) - personally i'd like it better if you'd use a QList<HighlightingRule> as it was before instead of a QHash for the regexps, as you only need to iterate over them, and no lookup based on keys. (or is there any special reason for using a QHash?) - indentations in sagehighlighter for keywords are a bit weird - apidocs should be added (but those were already missing before) Other than that, the patch looks good, and the performance is definately a lot better. I really like the fact that the API is completely independent of the underlying implementation(as in no QHash specific code in the headers).

- Alexander


On August 22nd, 2010, 9:06 p.m., Miha Cancula wrote:

Review request for KDE-Edu and Alexander Rieder.
By Miha Cancula.

Updated 2010-08-22 21:06:23

Description

As discussed on email, I implemented a different approach to highlighting in Cantor. I'd like some feedback before committing it. I introduced additional API in DefaultHighlighter and moved most of the logic in it, so the individual backend-specific highlighters only specify conditions (either QString or QRegExp) and matching text formats. The code looks much cleaner this way. As Alexander and Oleksiy already determined, breaking the text into words and looking for these words is faster than iterating over a huge list of regexes and looking for each of them in the text. That's why functions, variables and keywords are implemented this way. OTOH, thing like comments and strings are easier done using Regexes, so this functionality is still there. The implementation uses a QHash<QString, QTextCharFormat> and a QHash<QRegExp, QTextCharFormat>. If anyone knows of a way to make it faster, please say so. I also updated highlighters for Octave, Maxima and Sage to use the word-based API as much as possible. Most of their code was also removed, because it's now in DefaultHighlighter. I left R alone because Oleksiy's work is not yet in trunk.

Testing

I tested Maxima and Sage and they seem to be faster than before for large blocks. I used to have problems with non-smooth scrolling in Octave due to the large number of functions, but now it feels normal. I didn't notice any regressions (yet). It all works both on trunk and 4.4.

Diffs

  • /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.h (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.cpp (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.h (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.cpp (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.h (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.cpp (1166707)
  • /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.h (1166707)
  • /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.cpp (1166707)

View Diff

 
_______________________________________________
kde-edu mailing list
kde-edu <at> mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
Permalink | Reply | 0 comments |
headers
Miha Cancula | 24 Aug 2010 11:33
Picon
Gravatar

Re: : Review Request: Syntax Hightlighting in Cantor

This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5079/

On August 22nd, 2010, 8:15 p.m., Alexander Rieder wrote:

Hi, i haven't looked at the code yet, but in its current form the patch doesn't compile, as you try to include the non-existent "dbhighlighter.h" in octavehighlighter.h and sagehighlighter.h, and "highlightdatabase.h" in octavebackend.cpp.

On August 23rd, 2010, 6:17 p.m., Miha Cancula wrote:

I fixed the wrong includes, and I think the correct patch is up now.

On August 23rd, 2010, 8:06 p.m., Alexander Rieder wrote:

Hi, (i haven't tried the new patch, is it any different except for the includes?) some initial comments: - Octave Highlighter: operators, keywords variables are members but don't have m_ prefix. On purpose? - Sage Highlighter needs newline at end of file - use kDebug instead of qDebug (in DBHighlighter.cpp) - personally i'd like it better if you'd use a QList<HighlightingRule> as it was before instead of a QHash for the regexps, as you only need to iterate over them, and no lookup based on keys. (or is there any special reason for using a QHash?) - indentations in sagehighlighter for keywords are a bit weird - apidocs should be added (but those were already missing before) Other than that, the patch looks good, and the performance is definately a lot better. I really like the fact that the API is completely independent of the underlying implementation(as in no QHash specific code in the headers).
- No purpose, I also noticed that one of them isn't even used. I'll change that. - No problem, will add one - Of course, missed that one - Probably true, there's no reason for it, and easy to change since it's not exposed en the header. The QString one need a hash, so I just make the other one the same. - Will take a look. - About apidocs, I'll try to add them for the existing functions as well (primarily addPairs and highlightPairs).

- Miha


On August 22nd, 2010, 9:06 p.m., Miha Cancula wrote:

Review request for KDE-Edu and Alexander Rieder.
By Miha Cancula.

Updated 2010-08-22 21:06:23

Description

As discussed on email, I implemented a different approach to highlighting in Cantor. I'd like some feedback before committing it. I introduced additional API in DefaultHighlighter and moved most of the logic in it, so the individual backend-specific highlighters only specify conditions (either QString or QRegExp) and matching text formats. The code looks much cleaner this way. As Alexander and Oleksiy already determined, breaking the text into words and looking for these words is faster than iterating over a huge list of regexes and looking for each of them in the text. That's why functions, variables and keywords are implemented this way. OTOH, thing like comments and strings are easier done using Regexes, so this functionality is still there. The implementation uses a QHash<QString, QTextCharFormat> and a QHash<QRegExp, QTextCharFormat>. If anyone knows of a way to make it faster, please say so. I also updated highlighters for Octave, Maxima and Sage to use the word-based API as much as possible. Most of their code was also removed, because it's now in DefaultHighlighter. I left R alone because Oleksiy's work is not yet in trunk.

Testing

I tested Maxima and Sage and they seem to be faster than before for large blocks. I used to have problems with non-smooth scrolling in Octave due to the large number of functions, but now it feels normal. I didn't notice any regressions (yet). It all works both on trunk and 4.4.

Diffs

  • /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.h (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.cpp (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.h (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.cpp (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.h (1166707)
  • /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.cpp (1166707)
  • /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.h (1166707)
  • /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.cpp (1166707)

View Diff

 
_______________________________________________
kde-edu mailing list
kde-edu <at> mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
Permalink | Reply | 0 comments |
headers
Sebastian Stein | 24 Aug 2010 19:47
Picon
Picon

Re: : moving to git

Aleix Pol <aleixpol <at> kde.org> [100824 19:42]:
> I don't really understand your message, I know KDE is moving but we need to
> provide the rules file. Has this been done already? (besides marble) I don't
> think so...
> 
> We haven't discussed how do we want to work with the repository either.

I checked about 2 months back about the status and my assessment at that
time was that it is too early to do something. In the past, KDE Edu has
never been on the brink of KDE and I think this won't be different with GIT.
So I guess KDE Edu will move to git when the majority of projects do.

Best wishes,

Sebastian
--

-- 
http://sebstein.hpfsc.de/
Permalink | Reply | 4 comments |
headers
Aaron J. Seigo | 24 Aug 2010 20:41
Picon
Favicon
Gravatar

Re: : moving to git

On Tuesday, August 24, 2010, Aleix Pol wrote:
> Er... yes sure, but we as KDE Edu developers need to start that move, even
> if we're going to move along with the rest.

indeed; we need all the people helping out we can, and it's best if whomever 
writes the migration rules for svn2git has some knowledge of the repository 
being moved (e.g. kdeedu would be best done by people involved in kdeedu :) 
since that is where the greatest amount of knowledge around what branches are 
useful to bring over, etc. exists

> As you can see in the wiki above, it's not too early anymore.

what i would suggest is to wait for the results of the decision on what the 
policy should be for modules included in the SC releases. it would be best if 
all the modules followed the same pattern for consistency and continuity.

right now, sys admin is drafting a paper outlining the implications of our new 
git infrastructure (git + gitolite + redmine + ...) when it comes to 
repository structure. they have said this will be ready in the next 2 weeks.

that document will then be taken by the people on the scm-interest list and a 
decision will be made as to what path to take. we're still waiting on a 
timeline from that mailing list for that. (but i'll be pushing on them to do 
so if they don't provide us with a timeline soon.)

once that is done, we'll know exactly what direction to go with the modules. 
in the meantime, the most useful things that can be done by communities like 
KDE Edu is to figure out who can / will help with writing the rules and for 
those people to become familiar with the svn2git tool.

--

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

_______________________________________________
kde-edu mailing list
kde-edu <at> mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
Permalink | Reply | 1 comment |
headers
Alexander Rieder | 24 Aug 2010 21:06
Picon

Re: : Review Request: Syntax Hightlighting in Cantor

This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5079/

Hi, some more comments: - the apidoc has a typo: DefualtHighlighter , spicific - is qHash(const QRegExp& regExp) still needed? - you should use a foreach for iterating over the regexpRules - i think the "position changed, rehighlight block" and "cleaning up last block" should be removed/commented out. they just slow things down. The code there should be solid and not need this debugging anymore otherwise it looks good

- Alexander


On August 24th, 2010, 6:34 p.m., Miha Cancula wrote:

Review request for KDE-Edu and Alexander Rieder.
By Miha Cancula.

Updated 2010-08-24 18:34:08

Description

As discussed on email, I implemented a different approach to highlighting in Cantor. I'd like some feedback before committing it. I introduced additional API in DefaultHighlighter and moved most of the logic in it, so the individual backend-specific highlighters only specify conditions (either QString or QRegExp) and matching text formats. The code looks much cleaner this way. As Alexander and Oleksiy already determined, breaking the text into words and looking for these words is faster than iterating over a huge list of regexes and looking for each of them in the text. That's why functions, variables and keywords are implemented this way. OTOH, thing like comments and strings are easier done using Regexes, so this functionality is still there. The implementation uses a QHash<QString, QTextCharFormat> and a QHash<QRegExp, QTextCharFormat>. If anyone knows of a way to make it faster, please say so. I also updated highlighters for Octave, Maxima and Sage to use the word-based API as much as possible. Most of their code was also removed, because it's now in DefaultHighlighter. I left R alone because Oleksiy's work is not yet in trunk.

Testing

I tested Maxima and Sage and they seem to be faster than before for large blocks. I used to have problems with non-smooth scrolling in Octave due to the large number of functions, but now it feels normal. I didn't notice any regressions (yet). It all works both on trunk and 4.4.

Diffs

  • /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.h (1166762)
  • /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.cpp (1166762)
  • /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.h (1166762)
  • /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.cpp (1166762)
  • /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.h (1166762)
  • /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.cpp (1166762)
  • /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.h (1166762)
  • /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.cpp (1166762)

View Diff

 
_______________________________________________
kde-edu mailing list
kde-edu <at> mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
Permalink | Reply | 0 comments |
headers
Thomas Thym | 24 Aug 2010 23:10
Favicon

: Inviting the RKWard team to KDE

Hi all,

although Cantor has some R capabilities, too, RKWard is a very nice
(and imho more mature) app. RKWard is based on KDElibs.
A couple of days ago the idea to invite the RKWard team to KDE was
mentioned on the promo list. We think we could both gain from that.
But that's non of our (promo) business.

So what do you think?

Cheers,
Thomas
Permalink | Reply | 6 comments |
headers
Aleix Pol | 25 Aug 2010 00:03
Picon
Favicon
Gravatar

Re: : Inviting the RKWard team to KDE

On Tue, Aug 24, 2010 at 11:10 PM, Thomas Thym <ungethym <at> mevin.net> wrote:
Hi all,

although Cantor has some R capabilities, too, RKWard is a very nice
(and imho more mature) app. RKWard is based on KDElibs.
A couple of days ago the idea to invite the RKWard team to KDE was
mentioned on the promo list. We think we could both gain from that.
But that's non of our (promo) business.

So what do you think?

Cheers,
Thomas
_______________________________________________
kde-edu mailing list
kde-edu <at> mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu

I'm speaking from the ignorance, but some questions come up.

What do RKWard developer(s) think?

What does RKWard do that Cantor doesn't? Is it really the same application?

Would RKWard developers willing to integrate into cantor at some point in the future?

Aleix
_______________________________________________
kde-edu mailing list
kde-edu <at> mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
Permalink | Reply | 4 comments |

Gmane