Re: Splitting kde-workspace and kde-runtime proposal

[andrea diamantini]

I don't clearly understand why KUriFilter-Plugins should go to plasma-
workspace. I noticed KUriFilter is defined in kio and its plugins are used
e.g. in kparts (browserextension). Shouldn't these go to kio?


2014/1/22 Kevin Ottens 

> On Tuesday 21 January 2014 12:05:26 Antonis Tsiapaliokas wrote:
> > > 1) Create two different groups named plasma-workspace and
> > > plasma-desktop like frameworks
> > > 2) Split out every component into individual repos
> > > 3) Assign repos to the related group.
> > >
> > > Advantages:
> > >
> > > 1) Easy to assign maintainer to individual component.
> > > 2) If we split only some repos, we can not mark it as part of
> > > workspace but this way we can do it.
> > > 3) More, may be?
> > >
> > > That's my humble suggestion. :)
> > >
> > > > Again, this is a proposal so please! send any feedback you might
> have.
> > >
> > > Thanks!
> >
> > I think that splitting each individual component to its own repo might
> be a
> > bit confusing. Because if we don't have two groups (plasma-desktop and
> > plasma- workspace), then we will not be able to provide something as a
> > standard solution. So each person will consider  "Plasma Desktop" as
> > something entirely different.
>
> Note however that it's not a proper argument for splitting repos or not
> since
> nowadays our infrastructure has the concept of grouping independently of
> the
> repos. So we could split in their own repo and still have a way to make a
> plasma-desktop and a plasma-workspace group.
>
> OTOH Sebas argument is much more compelling.
>
> Regards.
> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> KDAB - proud supporter of KDE, http://www.kdab.com
>



-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: Git Scratch-Pads for every identity.kde.org account (not only developers)

[Andrea Diamantini]

On Thursday 30 December 2010 17:55:35 Milian Wolff wrote:
> Hey all,
> 
> I want to bring this topic to discussion. As developer of KDevelop and Kate
> I'm forced to jump through hoops to get code by new contributors in.
> 
> Right now the workflow is like this:
> 
> - new contributor says he has a patch
> - asked to created account on identitiy.kde.org
> - asked to put patch on reviewboard
> - gets reviewed
> - if it's a single commit patch, I ask him to use git format-patch and send
> me the commit so I can git am it
> - if it's a new feature or a big bugfix consisting of several commits the
> above is just a royal pita, hence I ask him to make his git branch public
> somewhere (gitorious, github, ...)
> 
> What I'd like to see improved:
> 
> - give every i.k.o account the ability to use his scratch pad without
> having the developer status.
> - make it possible to create a review board entry based on a branch in a
> scratch pad repo. Bonus points for automatic/easier update of the diff
> based on this branch. And I know that reviewboard does not support
> anything but single patches (yes, I don't like this as well but I can live
> with it), yet something like `git diff $branch..master` can be automated.
> 
> And for the final merging of commits I could simply add their clone as a
> remote and merge it just like I used to do on gitorious.
> 
> BTW: Opening up scratch pad repos is probably also good for new people
> working on completely new plugins or apps, since they can use our git
> infrastructure from the beginning without first having to use
> gitorious/github/... I know that most people will run into problems sooner
> or later and need me or someone else to take a look at their code, hence
> "just work in a local clone at the beginning" is not an option.
> 
> Bye

+1 from here.
In rekonq development and being used to gitorious and easyness of git remotes, 
we really suffer from this situation.
I know KDE people is used to reviewboard + svn and I can understand that it 
simply adds "something more" to the usual svn development workflow.
But this is not the same with git, being it decentralized and having remotes 
and bla bla. In the git case, it seems "forcing" a different workflow from what 
seems natural and easier (pulling the remote branch).
I also noticed people tending to just comment what is "visible" and "easy" in 
reviewboard (wrong coding style, unuseful changes in the code, etc..) instead 
of downloading/applying/testing locally the patch. Thing that never happened 
before.

Is it just us not (yet) used enough to the new situation or is it a real 
problem?

Regards,
-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rek...@freenode

Re: Git Scratch-Pads for every identity.kde.org account (not only developers)

[Andrea Diamantini]

On Sunday 02 January 2011 01:25:19 Eike Hein wrote:

> > So this is essentially a "CLOSED/WONTFIX" from your side then - too bad.
> > Any other takers? Esp. considering how others (rekonq) already voiced
> > themself in support of my request.
> 
> Assuming there's widespread support for the idea as such and
> concerns about it can be eliminated, it's more a LATER than
> a WONTFIX really. It's just that we don't think it'd be wise
> to take this on right now with so many other known and more
> pressing todos. There's also a let's-finish-what-we-started
> aspect to it. You're programmer and understand the cost of
> context switches - applies to people too.

Uhm... I was not really sustaining the "free scratchpad/playgroung" idea.
I was noting something that is considered obvious from rekonq developers: 
applied to git, "gitorious system" (let me call this way) is better than 
reviewboard one. And we are suffering for this.
We need a way, hopefully based on a web review system, to know the location of 
the remote git branch where the code is.
If someone wants to contribute, I don't mind if he has a git clone on 
git.kde.org / gitorious / github / gitsomething, I'd like to have an automatic 
and shared system to grab this remote branch.


-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rek...@freenode

Re: Review Request: Fix the inability to put an ioslave on hold when using the KIO-QNAM integration class...

[Andrea Diamantini]

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



trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp
<http://svn.reviewboard.kde.org/r/6183/#comment10504>

I'm studying and testing your patch. I  have just a stupid question 
actually: this "remove hold state" slot seems called just on cancel. Is this 
ok?  


- Andrea


On 2011-01-03 03:49:54, Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6183/
> ---
> 
> (Updated 2011-01-03 03:49:54)
> 
> 
> Review request for kdelibs and Andrea Diamantini.
> 
> 
> Summary
> ---
> 
> The attached patch fixes a long standing issue in the KIO-QNAM class where 
> actions that require putting an ioslave on hold currently do not work. In 
> kdewebkit, which uses this integration class, such actions always occur when 
> you click on a link that cannot be directly handled by the browsing engine. 
> For example, clicking on a link that points to a PDF link. Even worse is when 
> the link you click on results in an http POST which returns content. In such 
> cases, apps that rely on kdewebkit and hence the KIO-QNAM bridge class have 
> no way of putting an ioslave on hold as stated in KIO::get's documentation in 
> order to properly deal with content types they do not support.
> 
> The attached patch along with another pending against kio_http, 
> http://reviewboard.kde.org/r/6182/, remedies this issue by adding a means to 
> put replies on hold and fixing the downloadResponse slot in KWebPage to do 
> the right thing.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdelibs/kdewebkit/ISSUES 1211077 
>   trunk/KDE/kdelibs/kdewebkit/kwebpage.h 1211077 
>   trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanager.h 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanager.cpp 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.h 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.cpp 1211077 
> 
> Diff: http://svn.reviewboard.kde.org/r/6183/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit
> 
>

Re: Review Request: [PATCH] Make KIO::Scheduler correctly re-use ioslaves that have been put on hold...

[Andrea Diamantini]

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



/trunk/KDE/kdelibs/kio/kio/scheduler.cpp


typo?


- Andrea


On 2011-01-04 05:51:44, Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6271/
> ---
> 
> (Updated 2011-01-04 05:51:44)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> ---
> 
> The patch attempts to fix the following two oustanding problems in 
> KIO::Scheduler that have been around for a while (see the possibly related 
> bug reports in the Bugs section above):
> 
> #1. Set the m_checkOnHold flag to true every time 
> Scheduler::publishSlaveOnHold is invoked. Right now that flag is only set to 
> true when an instance of KIO::Scheduler is created. This results in the flag 
> never being true after the first ioslave has been put on hold and reused 
> unless the programmer explicitly calls KIO::Scheduler::checkSlaveOnHold which 
> is not documented at all. See the description about putting ioslaves on hold 
> in KIO::get's API documentation.
> 
> #2. Modify SchedulerPrivate::doJob to correctly set the m_checkOnHold flag 
> for http requests when a job's command is CMD_SPECIAL.  That is necessary 
> because HTTP_POST, which is handled as a special command, can return content 
> just like a get request.
> 
> 
> This addresses bugs 123121 and 148307.
> https://bugs.kde.org/show_bug.cgi?id=123121
> https://bugs.kde.org/show_bug.cgi?id=148307
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/kio/kio/scheduler.cpp 1209936 
> 
> Diff: http://svn.reviewboard.kde.org/r/6271/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit
> 
>

Re: Review Request: Fix the inability to put an ioslave on hold when using the KIO-QNAM integration class...

[Andrea Diamantini]

> On 2011-01-04 01:28:06, Andrea Diamantini wrote:
> > trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp, line 421
> > <http://svn.reviewboard.kde.org/r/6183/diff/3/?file=43369#file43369line421>
> >
> > I'm studying and testing your patch. I  have just a stupid question 
> > actually: this "remove hold state" slot seems called just on cancel. Is 
> > this ok?
> 
> Dawit Alemayehu wrote:
> It is not only called when you press cancel, but also if the the 
> application you chose to open the request with is non-KDE application. IOW, 
> we kill the ioslave we put on hold whenever it is not going to be used...
> 
> For your tests, you can use the test links marked "Movie" and "PDF" at 
> 
> 
> https://projects.kde.org/projects/extragear/base/kwebkitpart/repository/revisions/master/changes/tests/link_tests.html
> 
> Another good site for testing content-disposition is
> 
> http://greenbytes.de/tech/tc2231/
> 
> Please note that the html links at that site might expose known 
> limitations with the current put slave on hold mechanism when multiple KDE 
> browsers are involved. This limitation is marked as HACK in the kwebpage 
> patches.

Ok, thanks :)


- Andrea


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


On 2011-01-04 03:26:26, Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6183/
> ---
> 
> (Updated 2011-01-04 03:26:26)
> 
> 
> Review request for kdelibs and Andrea Diamantini.
> 
> 
> Summary
> ---
> 
> The attached patch fixes a long standing issue in the KIO-QNAM class where 
> actions that require putting an ioslave on hold currently do not work. In 
> kdewebkit, which uses this integration class, such actions always occur when 
> you click on a link that cannot be directly handled by the browsing engine. 
> For example, clicking on a link that points to a PDF link. Even worse is when 
> the link you click on results in an http POST which returns content. In such 
> cases, apps that rely on kdewebkit and hence the KIO-QNAM bridge class have 
> no way of putting an ioslave on hold as stated in KIO::get's documentation in 
> order to properly deal with content types they do not support.
> 
> The attached patch along with another pending against kio_http, 
> http://reviewboard.kde.org/r/6182/ , remedies this issue by adding a means to 
> put replies on hold and fixing the downloadResponse slot in KWebPage to do 
> the right thing.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdelibs/kdewebkit/ISSUES 1211077 
>   trunk/KDE/kdelibs/kdewebkit/kwebpage.h 1211077 
>   trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanager.h 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanager.cpp 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.h 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.cpp 1211077 
> 
> Diff: http://svn.reviewboard.kde.org/r/6183/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit
> 
>

Re: Review Request: Fix the inability to put an ioslave on hold when using the KIO-QNAM integration class...

[Andrea Diamantini]

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



trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp
<http://svn.reviewboard.kde.org/r/6183/#comment10529>

I studied a bit the testing sites you gave me. I noticed that the download 
diff link in reviewboard does not work well with rekonq and konqueror (filename 
info NOT used). If I understood things well, the content-disposition header 
should be checked for filenames also having the "inline" value.
So, something like:
if(value.startsWith(QL1S("attachment"),...) || 
value.startsWith(QL1S("inline")...)

I tested on rekonq code and it seems working.


- Andrea


On 2011-01-05 06:21:31, Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6183/
> ---
> 
> (Updated 2011-01-05 06:21:31)
> 
> 
> Review request for kdelibs and Andrea Diamantini.
> 
> 
> Summary
> ---
> 
> The attached patch fixes a long standing issue in the KIO-QNAM class where 
> actions that require putting an ioslave on hold currently do not work. In 
> kdewebkit, which uses this integration class, such actions always occur when 
> you click on a link that cannot be directly handled by the browsing engine. 
> For example, clicking on a link that points to a PDF link. Even worse is when 
> the link you click on results in an http POST which returns content. In such 
> cases, apps that rely on kdewebkit and hence the KIO-QNAM bridge class have 
> no way of putting an ioslave on hold as stated in KIO::get's documentation in 
> order to properly deal with content types they do not support.
> 
> The attached patch along with another pending against kio_http, 
> http://reviewboard.kde.org/r/6182/ , remedies this issue by adding a means to 
> put replies on hold and fixing the downloadResponse slot in KWebPage to do 
> the right thing.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdelibs/kdewebkit/ISSUES 1211858 
>   trunk/KDE/kdelibs/kdewebkit/ISSUES 1211858 
>   trunk/KDE/kdelibs/kdewebkit/kwebpage.h 1211858 
>   trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp 1211858 
>   trunk/KDE/kdelibs/kio/kio/accessmanager.h 1211858 
>   trunk/KDE/kdelibs/kio/kio/accessmanager.cpp 1211858 
>   trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.h 1211858 
>   trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.cpp 1211858 
> 
> Diff: http://svn.reviewboard.kde.org/r/6183/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit
> 
>

Re: Review Request: Add KMessageWidget, an alternative to KMessageBox

[Andrea Diamantini]

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


I cannot properly review your code. Ill just say I like this new GUI object 
very much! many thanks for :)

- Andrea


On April 29, 2011, 1:44 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101249/
> ---
> 
> (Updated April 29, 2011, 1:44 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> ---
> 
> KMessageWidget is a new widget which can be considered as a less intrusive 
> alternative for KMessageBox. It was designed during KDE UX sprint 2011 ( 
> http://community.kde.org/Sprints/UX2011/KMessageWidget ).
> 
> The class documentation should make it clear how and when it can be used.
> 
> This widget could be used by:
> - Browsers to implement their "remember password" widgets (Konqueror, 
> Rekonq...)
> - Forms to provide feedback on validation errors
> - Bluedevil KCM to replace its custom "No Bluetooth adapter have been found" 
> message widget
> - Nepomuk/Strigi KCM to indicate status of their services
> - Gwenview to replace its custom save bar
> - ...
> 
> I still have a few additions in mind for the API but it is already usable and 
> since we are freezing I think it can be merged in master in its current 
> state. I assume it will still be possible to extend the API a bit before 
> kdelibs 4.7 freezes for good.
> 
> I also wrote an example program in the kdeexample repository ( 
> https://projects.kde.org/projects/kde/kdeexamples/repository/show?rev=agateau%2Fkmessagewidget
>  ), though I am wondering whether it shouldn't be moved in kdeui/tests as it 
> is more a manual test program than an example.
> 
> 
> Diffs
> -
> 
>   kdeui/CMakeLists.txt d1873d1 
>   kdeui/widgets/kmessagewidget.h PRE-CREATION 
>   kdeui/widgets/kmessagewidget.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/101249/diff
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> Montage from kmessagewidgetdemo
>   http://git.reviewboard.kde.org/r/101249/s/141/
> 
> 
> Thanks,
> 
> Aurélien
> 
>

Re: Git Worflow, branch creation.

[Andrea Diamantini]

On 05/17/2011 05:52 PM, Ivan Cukic wrote:

On Tuesday, 17. May 2011. 11.42.41 Maksim Orlovich wrote:

Testing.

If everyone is working on branches on cool new stuff, the release will
be crap.

I don't agree. Freezes just stop the development - it doesn't improve the
bugfixing as much.

The best way (IMO) would be to have all done in parallel.

Cheerio,
Ivan
In my little experience, the process works well when you decide some 
"minimal stability level" to absolutely respect.
If kdelibs stability level until freeze is "it has to compile", it will 
be very a long and hard debugging period.
But if the level is "you can use it instead of branch version" things 
will be easier.
So, the idea is to let master being every time open for new features, 
but enhance the "I can push" step.

Obviously the enhancement is the first step.


Just my 0.02 cents.

--
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: Formal complaint concerning the use of the name "System Settings" by GNOME

[Andrea Diamantini]

On 07/24/2011 05:11 PM, Emmanuele Bassi wrote:

applications using the org.freedesktop.Secrets API will ask for the 
well-known bus name, and get to talk to the daemon implementing it; 
that means using the gnome-keyring daemon or kwallet, depending on 
which is installed. the same mechanism of auto-activation is used for 
many other things. 
A bit out of topic, just let me say that this secrets/wallet/keyring 
thingy is really cool ;)


Ciao,

--
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: Formal complaint concerning the use of the name "System Settings" by GNOME

[Andrea Diamantini]

On 07/24/2011 09:10 PM, Michael Jansen wrote:
I btw. agree that a kde application outside of a kde workspace should 
be self contained. We could solve that problem btw inside of the kde 
framework even. As Martin masterfully proved systemsettings is a 
workspace application and should not be be required outside of a full 
kde workspace (if someone decides to install it intentionally it 
should still work so the original problem has to be solved anyway.) A 
application could recognize that it is run outside of an active kde 
workspace and add all needed kcms (which should be as less as possible 
) to its settings menu in that case. But we should really try to 
respect of the active workspaces settings as possible therefore making 
as muss kcms as possible useless in such an environment. Mike


Given that, it seems clear to me that all "important" and "shared" KCMs 
should live in kde-runtime. Isn't it?


Regards,

--
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: Formal complaint concerning the use of the name "System Settings" by GNOME

[Andrea Diamantini]

On 07/25/2011 04:53 PM, Aaron J. Seigo wrote:

On Monday, July 25, 2011 12:19:19 Andrea Diamantini wrote: KCMsshould live in
kde-runtime. Isn't it?

they do.


So, it's just my bad luck the ones I use (cookies, proxy, cache) are not.
Working for a solution...

--
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: My Plans, Your Plans: Berlin Desktop Summit

[Andrea Diamantini]

On 07/27/2011 03:40 PM, Aaron J. Seigo wrote:

hi :)

BDS is coming up rather quickly and i've been doing some personal planning for
it today. i realized in one of those "i just realized the obvious, doh!"
moments that i have very little idea of what others are planning and hoping
for the event. it was a quick hop from there to realize that probably nobody
knew what i planned and hoped for either.

given that this is one of the most important events in KDE's annual calendar,
this was a little shocking to me once i thought about it. i'd like to help
make BDS a raging success this year for us (and i'm sure you all want and
expect the same :) and it would help if i (and others) could arrive with some
idea of what we're all arriving with in terms of expectations.

so .. here are my primary goals:


My plans for the desktop summit are

* finally meet people behind some nicks

* understand a bit better (and eventually organize) this "active browser"

* try to organize a sort of meeting (annual?) for people interested in 
"web/network applications" (konquers, rekonquers, kdewebkitters & 
khtmlers, kioers, nice girls, etc..)


and...

* have an enjoyable time with everyone who shows up :)



Cheers,

--
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: The future of Power Management - together with Activities

[Andrea Diamantini]

On Saturday 01 October 2011 20:07:12 Stefan Majewsky wrote:
> Actually I'm confused by the concept of activities as a whole: On
> one hand, there are libraries now for reacting to activity switching.
> On the other hand, activities are said to include running
> applications, so apps will be closed when switching to a different
> activity. That seems contradictory.
> 
> That makes it difficult for me to see where power profiles come into
> this game: Does this mean that when I want to switch to a different
> profile, does this mean that I have to create a new activity when I
> want to change to a different power profile, which would mean that all
> running applications would close because they belong to the previous
> activity?

OT question about activities: how can they manage stop/restart of applications 
inside them? What about eg singletons?

About Power Management; having the ability to manage the 3 main profiles is 
everything I need. So, having an easier way to do it is an improvement for the 
users, IMHO.

I don't have a clear idea about activities, as I'm not used to. But the idea 
expressed in your mail makes sense to me.
So, +1 from here.

Cheers,
-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)

[andrea diamantini]

I think that every app using cookies would like to have this patch merged
ASAP, expecially browsers.
This will help/fix/improve features like "private browsing" and so on.
So please don't let us wait for the "big Universe reordering" to have it. :)

2011/11/8 Aaron J. Seigo 

> On Monday, November 7, 2011 19:32:15 Dawit A wrote:
> > >> Well this is over a month too late, but I have a enhancement change
> > >> for kcookiejar that needs to go into kdelibs/kioslave for KDE 4.8. The
> > >> patch has actually been pending for a merge since KDE 4.6. See
> > >> https://bugs.kde.org/show_bug.cgi?id=54300.
> ...
> > Right. The patch simply moves the idea of session cookies from being a
> > global configuration option to a site specific option. That is it gets
> > rid of the all or nothing approach currently employed. That gives the
> > user a lot more control of how they deal with cookies.
>
> can you explain why it must go into 4.8? it's been waiting since 4.6, and i
> didn't find a description of what requires it in 4.8 ...
>
> as far as i can see, it's a feature enhancement that isn't strictly
> required
> by anything (though it is very nice to have indeed), so it should go into
> the
> frameworks branch.
>
> --
> 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
>

Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)

[Andrea Diamantini]

On Wednesday 09 November 2011 16:45:55 Aaron J. Seigo wrote:
> On Wednesday, November 9, 2011 15:28:48 andrea diamantini wrote:
> > I think that every app using cookies would like to have this patch
> > merged
> > ASAP, expecially browsers.
> > This will help/fix/improve features like "private browsing" and so on.
> > So please don't let us wait for the "big Universe reordering" to have
> > it. :)
> help us make the "big universe reording" happen and everyone will get these
> kinds of changes sooner.
> 
> frameworks needs to happen. to happen, it needs people working on it. if we
> continue to allow ourselves to work on 4.x instead  well, the math is
> simple.
> the problem here is that people do not yet consider frameworks to be the
> next version of kdelibs. it has not yet sunk in that, yes, indeed kdelibs
> 4.x is done. bug fixes are welcome and encouraged, of course, and are
> merged into frameworks.
> 
> but we need to shift into a mindset where framework _is_ the next version of
> kdelibs. not something for someone else to work on and give us in some far
> distant undetermined future, but for us to work on so we can have it sooner
> rather than later.

4.x is where I'm living/fighting/coding/writing now.
I'm sorry to say, in my mind next version of kdelibs is 4.8. And it will be 
based on the upcoming (not yet released) Qt 4.8.

Thinking about "frameworks" without having yet a decent idea of what will be 
Qt5 is impossible for me. But probably it's me, because I usually start coding 
after 10pm...

-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)

[andrea diamantini]

2011/11/10 Aaron J. Seigo 

> On Wednesday, November 9, 2011 23:44:21 Andrea Diamantini wrote:
> > 4.x is where I'm living/fighting/coding/writing now.
>
> for apps and workspaces, that is perfect. we don't want to disrupt app and
> workspace development while we get kdelibs prepped for the next major
> release.
>
> > I'm sorry to say, in my mind next version of kdelibs is 4.8.
>
> your mind is wrong. whatever the version number might end up saying
> (probably
> to keep packagers and users from confusion) it'll be the 4.7 code base with
> continued bug fixes applied :)
>
> > And it will be based on the upcoming (not yet released) Qt 4.8.
>
> sure; but this is a non-relevant detail.
>
> > Thinking about "frameworks" without having yet a decent idea of what
> will be
> > Qt5 is impossible for me.
>
> actually, Qt5 is irrelevant to most of the work that needs to be done in
> frameworks. we can, and are, working against Qt4 right now. most of the
> work
> is modularization and modernization (while preserving source compatibility)
>

Ok, stupid question then. Why aren't we releasing this as kdelibs 4.8?


>
> we are merging some things upstream into Qt5, and the things that are
> merged
> upstream are going into a small temporary library call libinqt (lib in qt
> ;).
> when Qt5 arrives, that library will go away and we will be able to move to
> basing frameworks on Qt5. between now and then there is a lot of work on
> the
> modularization and modernization work.
>
> for instance, Sune's proposal to improve KNotification requires absolutely
> nothing from Qt5. having that done before Qt5 arrives would actually be a
> bonus as we wouldn't have to juggle too many different kinds of changes at
> once.
>
> i do recognize that there is not enough documented plans and direction for
> frameworks 5. there are a handful of wiki pages but they do not contain
> enough
> information; too much of that still resides in the heads of just a few
> people.
>
> to help address that, i'm hosting an irc meeting in a couple weeks with
> people
> currently working on frameworks 5 with the aim of pulling together clearly
> documented goals, tasks and milestones. the date has not been fixed yet,
> once
> it is i will announce it here as well so interested parties can join.
>
> i hope that with further documentation and clairty of goals that others
> will
> be able to see how they can get involved with frameworks and why now is a
> good
> time to do so.
>
>

I hope that, too :)



>  --
> 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
>

Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)

[Andrea Diamantini]

On Saturday 12 November 2011 12:26:11 Sebastian Kügler wrote:
> On Wednesday, November 09, 2011 15:28:48 andrea diamantini wrote:
> > I think that every app using cookies would like to have this patch
> > merged
> > ASAP, expecially browsers. This will help/fix/improve features like
> > "private browsing" and so on. So please don't let us wait for the "big
> > Universe reordering" to have it. :)
> 
> To me, this is typically a "nice to have" feature. Sure, very cool stuff,
> but does it warrant changing the plans we made this Summer to move to
> Frameworks5 as fast as we can?
> 
> I don't think it does, therefore, I'm against breaking the feature freeze
> and have us rather concentrate on making the "Big Universe Reordering"
> happen. (There are people waiting for that to happen, too, after all.)
> 
> The mantra should be "If you want a new feature in kdelibs, help us making
> the next feature release of it happen".

Ok, let's wait 18 months to see private browsing fixed. Going to update bug 
reports...

-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: KIO / KWebView and PrivateBrowsing (Cookies)

[Andrea Diamantini]

On 04/26/2012 05:17 PM, Alex Fiestas wrote:

On Wednesday, April 25, 2012 04:26:28 PM Dawit A wrote:


If you wait a litte while I am going to fix this issue once and for all
since I want to add proper support for "Private browsing mode" in
kwebkitpart. I am sure the reKonq guys/gals will appreciate that as well.

Oookz !



WOW!
We surely are interested and we'll appreciate it a lot. So this is 
something that can be implemented without touching actual kdelibs, 
right? So a potential "next month" feature :D ?!

Re: Package Dependcies List on Techbase

[Andrea Diamantini]

On Monday 07 May 2012 11:36:38 Allen Winter wrote:
> Howdy,
> 
> I started putting the list of package dependences (arranged by module) onto
> Techbase. http://techbase.kde.org/Getting_Started/Build/Requirements
> 
> The tables on the subpages there are generated by a perl program I wrote.
> That program reads the CMakeLists.txt files inside a module and generates
> wiki content I then copy+paste into Techbase.
> 
> Please review for accuracy.
> 
> For example: Why are attica and phonon REQUIRED for kde-runtime??
> 
> I'll be finishing up the list in the coming days.

Stupid question: doesn't kdelibs depend on Qt?

-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: Review Request: Move the Preferred Web shorcut selection checkbox into its own column

[Andrea Diamantini]

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

Ship it!


Ship It!

- Andrea Diamantini


On May 9, 2012, 8:35 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104900/
> ---
> 
> (Updated May 9, 2012, 8:35 p.m.)
> 
> 
> Review request for KDE Runtime.
> 
> 
> Description
> ---
> 
> The following patch moves the "Preferred/Favorite" web shortcut selection 
> checkbox into its own column to avoid confusion. The new column is marked as 
> "Preferred" and also shows a tool tip message about is functionality. See the 
> screenshot below.
> 
> 
> This addresses bugs 168223 and 218164.
> http://bugs.kde.org/show_bug.cgi?id=168223
> http://bugs.kde.org/show_bug.cgi?id=218164
> 
> 
> Diffs
> -
> 
>   kurifilter-plugins/ikws/ikwsopts.cpp f1cc481 
>   kurifilter-plugins/ikws/ikwsopts_p.h 9cfc12c 
>   kurifilter-plugins/ikws/ikwsopts_ui.ui 440c201 
> 
> Diff: http://git.reviewboard.kde.org/r/104900/diff/
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> Preferred selection column
>   http://git.reviewboard.kde.org/r/104900/s/563/
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Re: Review Request: Move the Preferred Web shorcut selection checkbox into its own column

[Andrea Diamantini]

> On May 9, 2012, 9:34 p.m., Andrea Diamantini wrote:
> > Ship It!

I like it. And code changes seem easy and safe.


- Andrea


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


On May 9, 2012, 8:35 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104900/
> ---
> 
> (Updated May 9, 2012, 8:35 p.m.)
> 
> 
> Review request for KDE Runtime.
> 
> 
> Description
> ---
> 
> The following patch moves the "Preferred/Favorite" web shortcut selection 
> checkbox into its own column to avoid confusion. The new column is marked as 
> "Preferred" and also shows a tool tip message about is functionality. See the 
> screenshot below.
> 
> 
> This addresses bugs 168223 and 218164.
> http://bugs.kde.org/show_bug.cgi?id=168223
> http://bugs.kde.org/show_bug.cgi?id=218164
> 
> 
> Diffs
> -
> 
>   kurifilter-plugins/ikws/ikwsopts.cpp f1cc481 
>   kurifilter-plugins/ikws/ikwsopts_p.h 9cfc12c 
>   kurifilter-plugins/ikws/ikwsopts_ui.ui 440c201 
> 
> Diff: http://git.reviewboard.kde.org/r/104900/diff/
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> Preferred selection column
>   http://git.reviewboard.kde.org/r/104900/s/563/
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Re: Review Request: Rename Samba Shares to Windows Shares (SMB)

[andrea diamantini]

Just let me add my 2 cents to the discussion saying that whatever name you
are going to choose here, it should be non technical at all from the user
POV.
So, please let "samba", "smb" or similar out of it. "Windows" is
borderline. My mother knows that it is referred to something computer
related. :)

2012/6/22 Stas Verberkt 

> My mother however thinks about a certain latin dance when I tell her
>>> to 'use the samba share'.
>>>
>>
>> My mother however thinks about certain holes in the walls of her home
>> when I
>> tell her to 'use the windows share'.
>>
>>  Windows itself refers to this by "network share", I think.
> However, what I was wondering is: if a user does not understand those
> terms,
> would that user use these shares? Or would that user just use the link or
> shortcut he got from the system administrator? Because I am not sure if my
> mother would understand the whole concept of sharing anyway -- ok, I am
> telling
> a lie here, my mother is an IT professional, but that is not the point. ;)
>



-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

rekonq 2 merged in rekonq main repository

[andrea diamantini]

Hi all,
just a brief announce here saying that finally rekonq 2 code has been
merged in rekonq main repository. It's really not 100% new code, but I'll
be glad you can find one moment to review it.
Keys news I'll be glad to hear comments and hints about are:
- kwebapp remove and code reorganization to use the same web classes in all
the situations (check the webtab/ dir about)
- kmainwindow remove and session reimplementation (copied from kmainwindow)
in the "rekonqwindow" class (based now on qwidget, "ready" for the QML
transition, tabwindow/ dir).
- New private browsing mode (NOT based on KIO, as it seems our cookiejar is
not enough "malleable" for it. At least in kde4)

Hope you can help us let rekonq rock.
Regards,

-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: rekonq 2 merged in rekonq main repository

[andrea diamantini]

Yes, I'm obviously trying.
My first attempt was a tiny change in the KCookieServer/KCookieJar API to
let people search just for persistent cookies.
But it failed.
I'm currently working on a second attempt following the same approach. If
not, I though about implementing a different jar for the private sessions.
But this second idea is probably an "hard" change in the kde cookie jar.
I fear that "private sessions" are exactly the opposite idea around what
the "monolithic" & "share it with every app" kde cookie jar is builded.


2012/12/17 David Faure 

> On Sunday 16 December 2012 18:41:31 andrea diamantini wrote:
> > - New private browsing mode (NOT based on KIO, as it seems our cookiejar
> is
> > not enough "malleable" for it. At least in kde4)
>
> Are you working on patches to make it "malleable" enough in the future?
>
> If you need something, make it happen, don't just hope for others to do so
> :)
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
>


-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: rekonq 2 merged in rekonq main repository

[andrea diamantini]

The issue looks very similar, yes.


2012/12/19 Sebastian Kügler 

> On Tuesday, December 18, 2012 23:14:01 Dawit A wrote:
> > Well that is not entirely correct. We can definitely implement support
> for
> > private mode in the cookiejar itself easily. There are a couple of
> > approaches we can take. The difficult part has always been how to handle
> > the "private session" cookies in the cookie management dialogs. Anyhow, I
> > promised to try and implement this for 4.10, but I could not find the
> time.
> > Perhaps I will find some time during the upcoming holidays.
>
> Is this the same issue that we can't set an empty cookiejar on the webview?
> This issue bit me a while ago when using kdewebkit for an oauth
> implementation, I need an empty cookiejar there because I don't want to
> authenticate an already logged in user. This didn't seem possible, and I
> think
> the problem still exists. afiestas ran into the same issue.
>
> Or maybe I'm confusing this? :)
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>



-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: rekonq 2 merged in rekonq main repository

[andrea diamantini]

I though that way, too. My problem was just that implementing my ideas
about did not lead to a "working" solution. And I really cannot release
another time with a private "non-really-private" incognito mode.
About your difficulties, I can just say that, IMHO, "private session"
cookies have to be completely ignored even from the cookie dialog. They
cannot be stored on disk. And they have to disappear from memory as soon as
the private session ends.
That's because the "empty cookiejar problem" looks similar. And using Qt
network classes seems easier.
On QNAM you can create a QNetworkCookieJar on the fly, use and delete it
when your session finishes. With KIO you cannot do this as we have just ONE
cookiejar kde-wise. So the approach has to be:
- you cannot no more store cookies (dawit just implemented this, I think)
- you cannot no more use old cookies stored (my first attempt here failed)
- you have to manage your session "session cookies" (that is, use in your
private session and delete them when it (and NOT kde session) finishes).



2012/12/19 Dawit A 

> Well that is not entirely correct. We can definitely implement support for
> private mode in the cookiejar itself easily. There are a couple of
> approaches we can take. The difficult part has always been how to handle
> the "private session" cookies in the cookie management dialogs. Anyhow, I
> promised to try and implement this for 4.10, but I could not find the time.
> Perhaps I will find some time during the upcoming holidays.
>
>
> On Mon, Dec 17, 2012 at 7:18 PM, andrea diamantini wrote:
>
>> Yes, I'm obviously trying.
>> My first attempt was a tiny change in the KCookieServer/KCookieJar API to
>> let people search just for persistent cookies.
>> But it failed.
>> I'm currently working on a second attempt following the same approach. If
>> not, I though about implementing a different jar for the private sessions.
>> But this second idea is probably an "hard" change in the kde cookie jar.
>> I fear that "private sessions" are exactly the opposite idea around what
>> the "monolithic" & "share it with every app" kde cookie jar is builded.
>>
>>
>> 2012/12/17 David Faure 
>>
>>> On Sunday 16 December 2012 18:41:31 andrea diamantini wrote:
>>> > - New private browsing mode (NOT based on KIO, as it seems our
>>> cookiejar is
>>> > not enough "malleable" for it. At least in kde4)
>>>
>>> Are you working on patches to make it "malleable" enough in the future?
>>>
>>> If you need something, make it happen, don't just hope for others to do
>>> so :)
>>>
>>> --
>>> David Faure, fa...@kde.org, http://www.davidfaure.fr
>>> Working on KDE, in particular KDE Frameworks 5
>>>
>>>
>>
>>
>> --
>>
>>
>> Andrea Diamantini
>> WEB: http://www.adjam.org
>>
>> rekonq project
>> WEB: http://rekonq.kde.org
>> IRC: rekonq@freenode
>>
>>
>>
>


-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: Review Request: Add some new User Agent files for spoofing browser identities in konqueror, rekonq

[Andrea Diamantini]

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

Ship it!


Ship It!

- Andrea Diamantini


On Dec. 31, 2012, 10:25 p.m., Guillaume de Bure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108057/
> ---
> 
> (Updated Dec. 31, 2012, 10:25 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Description
> ---
> 
> I find that the current list of Browser identities that you can use in 
> konqueror or rekonq is so very obsolete... I used information from 
> http://www.useragentstring.com/pages/Browserlist/ and wrote some additional 
> .desktop files, specifically:
> * Chrome 22, 23, 24
> * Firefox 15, 16
> * IE 8, 9
> * Opera 11, 12
> * Safari 5, 6
> 
> I purposely did not update the CMakeLists.txt yet, waiting for some initial 
> feedback first. I also intend to remove some other entries from the current 
> file list, unsure whether that should come in a separate review request
> 
> 
> Diffs
> -
> 
>   konqueror/settings/kio/uasproviders/chrome22oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/chrome23oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/chrome24oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/firefox15oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/firefox16oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/ie80onwinnt60.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/ie90onwinnt71.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/op1162oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/op1202oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/safari517.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/safari60.desktop PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/108057/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Guillaume de Bure
> 
>

Re: Releases in 3 months

[andrea diamantini]

My idea about this concerns the way we let other people know aboout new
features. I usually read our feature plan (e.g.
http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan).
I think we could add one general page per project, similar to that one,
listing:
- the feature
- the branch where it is developed
- the developer
- the milestone (eg: kde 4.12, october 2103) where developer thinks to
merge/release.

Having such a central place to know about others' work could help a lot
getting informed (i.e. testing the features you'd like to test and not
having master broken cause of feature X development while you are working
on feature Y merge) and eventually plan a new KDE SC release (you'll know
more or less when people thinks to release new features).
If you have interesting new things, people will love a "two months
release". On the other hand, releasing every six months just because the
scheduler says so grabs out some attention.

Just my 2 cents


2013/7/9 Scott Kitterman 

> On Tuesday, July 09, 2013 02:02:48 AM Aleix Pol wrote:
> > On Mon, Jul 8, 2013 at 3:04 PM, Àlex Fiestas  wrote:
> > > Now that kde-workspace and kdelibs are going to be frozen (which in
> theory
> > > means less work for everybody) I'd like to propose a new release
> schedule
> > > to
> > > be applied starting with 4.12.
> > >
> > > Basically the idea is to cut testing time and compensate it by keeping
> > > master
> > > always in a "releaseable" state, now that two major components are
> frozen
> > > it
> > > looks like it is a good time to get used to it.
> > >
> > > You can read all the proposal in:
> > > http://community.kde.org/KDE_Core/ReleasesProposal
> > >
> > > Before sending this email I have checked with distro people, i18n
> people,
> > > other developers and almost all of them seemed to either like or be
> > > neutral
> > > about it (only one exception :p) so I hope that the proposal is not a
> > > complete
> > > disaster.
> > >
> > > As its name indicates, it is a proposal, so please be constructive in
> the
> > > feedback, we can change as many things as we need.
> > >
> > > Finally, I have scheduled a Bof at Akademy, would be nice to have all
> the
> > > feedback from the community that is not able to come before it happens:
> > >
> > > http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July
> > >
> > > Cheers !
> >
> > Hi,
> > I think this can be an important step forward in KDE. I see here that
> we're
> > essentially adding flexibility to our project delivery, it's something
> that
> > we've missed for longtime and I'd say that we want to use this
> opportunity
> > to our favor.
> >
> > Most of the arguments I see here are technical complaints about such a
> > management change. Most of us here are technologists and we can deal with
> > those changes. Moreover, we just adopted git and some developers are
> still
> > using it as svn.
> >
> > I think that agreeing upon having a clean and usable master will be
> healthy
> > for all KDE projects, one of the biggest problems I've had as a
> maintainer
> > is lack of future versions' users. We want those, and I know many KDE
> > developers who don't test regularly what our users will end up suffering.
> > This has to stop. Either way, I hope that our project maintainers will
> keep
> > making sure no unfinished features end up in our final releases.
>
> Getting this workflow firmly in place seems like a reasonable
> pre-requisite to
> the shorter release cycle.
>
> Scott K
>



-- 

Andrea Diamantini
WEB: http://www.adjam.org

Sponsored by BlueSystems to work on the rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: Releases in 3 months

[andrea diamantini]

What about a single official development branch?
Just use two branches:
- master branch (stable)
- kdevel branch (devel)
You develop wherever you like and push things on "kdevel" branch when
ready. If you like the "one branch approach", you devel things directly in
kdevel branch.
People knows there are just 2 important branches: master and kdevel. One
people per project can think merging from kdevel to master when things are
"ok".
I think this adds just a tiny layer for people working with one branch and
it is basically the same for "multibranches people". And it allows both
worlds to cohexists.



2013/7/11 Aurélien Gâteau 

> Le mercredi 10 juillet 2013 17:55:42 Àlex Fiestas a écrit :
> > On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote:
> > > Two point I want to mention:
> > > 1) working in a branch for kdepim is quite painful, as you need
> actually
> > > work on branches of 3 (or sometimes 4) modules: kdepimlibs,
> > > kdepim-runtime,
> > > kdepim (and akonadi). Keep them up-to-date, merge them at the right
> point,
> > > etc. Developing in master is *much* easier.
> >
> > I do this web KDE-Accounts integration, it is more painful but doable,
> not
> > like the month is ending like it was with svn.
> >
> > > 2) some people don't like branches, we have to understand it. :) There
> is
> > > no one schedule that will fit all, that's sure. But dismissing once
> > > preference with a way that tells him how he SHOULD do, is not really a
> > > good.
> >
> > Developing big features in master is even disrespectful to your fellow
> > developers, countless time things have broken because of this and people
> > have not been able to use master as their work environment.
> >
> > I could understand it for small things, and in the case you are an
> > exceptional developer that does not make mistakes and tests everything
> > before pushing. So maybe we can find a compromise? what about:
> >
> > Features can be developed in master, if they are big or delicate just add
> > compile option to remove them for release.
> >
> > This way we can we could even add something like
> > cmake -DDISABLE_WIP_FEATURES
> >
> > And then leave this up to each module developers to decide whether this
> way
> > of working is acceptable for them or not.
>
> This is an interesting approach, it could help for cross-repository
> features
> like a feature requiring changes in kdepimlibs and kdepim, it can also
> make it
> easier to test a feature while you are developing another one (basically it
> boils down to -DWITH_MY_FEATURE=ON -DWITH_SOMEONE_ELSE_FEATURE=ON)
>
> There are a few dangers with it though:
>
> - It adds more build system work, which can be error-prone.
>
> - Depending on how invasive the feature is, at one point you may/will
> commit
> code which builds for you but does not build with -DWITH_MY_FEATURE=OFF.
>
> - One must be careful to remove the CMake options after the feature is
> marked
> as stable, to avoid accumulating cruft.
>
> Aurélien
>



-- 

Andrea Diamantini
WEB: http://www.adjam.org

Sponsored by BlueSystems to work on the rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode

Re: Moving Baloo and Baloo-widgets into KDE SC

[andrea diamantini]

2013/12/27 Albert Astals Cid 

> What about the users of:
>  rekonq
>


I'll be happy to move to Baloo in the upcoming KF5 series. Rekonq just uses
Nepomuk to tag/rate bookmarks. I'll just need some explanations about
moving the actual info.

Cheers,

-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode