Re: Nepomuk in 4.13 and beyond

[Marco Martin]

On Thursday 12 December 2013, Vishesh Handa wrote:
> About 2 months ago we started to draft Baloo [1], a metadata solution
> that
> will cover the bare necessities of each use case we have.
> 
> I'd like to avoid getting into the technical details of the implementation
> in this thread. Another thread can be started about its different aspects
> once
> you've read the basic ideas behind Baloo [2]

First of all, I'm happy an alternative solution to virtuoso exists and is 
already at such advanced stage. Those days I was playing with nepomuk (among 
the other things) on ARM and the performance was a bit worrying.. however with 
this moving forward, I'm a good deal less worried now :D


That said, I fear there may be features that get lost, especially for active, 
I'll discuss those in the appropriate branch of the thread

Cheers,
Marco Martin

Re: Nepomuk in 4.13 and beyond

[Vishesh Handa]

On Thursday 12 Dec 2013 21:23:51 Aaron J. Seigo wrote:
> On Thursday, December 12, 2013 20:10:27 Vishesh Handa wrote:
> > On Thursday 12 Dec 2013 19:40:11 Ivan Čukić wrote:
> > > > If we all decide to store stuff in sqlite, then it doesn't matter if
> > > > they
> > > > are separate database files or the same one.
> > > 
> > > I might be missing a few things here, but asking questions is the road
> > > to
> > > enlightenment :)
> > > 
> > > - There is no way to query across different stores, which was the main
> > > appeal of nepomuk? (I concluded this from the last mail)
> > 
> > There isn't one. Not right now. I'm open to ideas on how to do something
> > like if it is required. I'm slightly skeptical if it actually is required.
> 
> for activities it’s pretty much a requirement: we have an activity and we
> want to know all resources (files, contacts, bookmarks, applications,
> windows ..) associated with it. so for activities we’ll either end up
> querying each store separately or Baloo will need to provide a way to query
> multiple stores.
> 
> for the Plasma Active shell as it currently is, single-store querying might
> be workable as we tend to keep most of the different resources separated in
> the UI (though that’s one thing i want to change in future releases, so you
> can group a set of bookmarks with a given file, e.g.)

I'm slightly confused.

Please correct me if I haven't understood the problem correctly - You have an 
activity and you have a number of different resources related to that activity. 
The resource can be a file/contact/application/bookmark/anything.

In order to store this, you could just store a mapping between activity id and 
resource id. Almost identical to what we have for tags. If this was stored in 
sql. Fetching everything related to a query would be -

select * from activityRelation where activityId = 'identifier';

Then, when displaying each of these resources, you would need to query the 
individual stores they are in. For Contact and Emails, this would be Akonadi. 
For files, there is a FileFetchJob, etc.

> 
> it would be a big problem if the tags are per-store as well; we need cross-
> store tags (though from glancing at the API tonight it looks like that is
> already there?)
> 

Yes. But I'm having second thoughts about this.

> this may be a question of API, of course. with different stores, collation
> will need to happen somewhere. should it happen on the client side or the
> server side is, i suppose, the big question.
> 
> i would suggest server side for a simple reason: if multiple stores all
> share the same physical storage system, it would be really nice to be able
> to optimize queries to hit that storage system as little as possible.
> example:
> 
> Stores: S0, S1, S2
> 
> S0 -> xapian
> S1 -> xapian
> S2 -> mysql
> 
> when fetching items from S0 and S1 that match tag T0, it would be very nice
> if the backends could cooperate to merge their queries into one so that one
> xapian query is done rather than 2 with post-query collation of the
> results.
> 
> for obvious reasons this can only be done in the server where the stores can
> cooperate.
> 
> a concrete use case:
> 
> S0 = files
> S1 = bookmarks
> S2 = applications
> 
> application = Plasma Active shell
> 
> if adding stores is easy enough, i expect we’ll end up with stores for
> things like geolocation, so this could balloon further.
> 
> > > - When querying, how do I get the properties of the results?
> > 
> > You don't. You just get the identifier and some text. You can do a
> > subsequent fetch job to get additional data.
> 
> more roundtrips doesn’t sound great for performance. if a result set has a
> 1000 returned items and you then want to get properties on them (e.g. for
> listing and sorting) then one needs to either send all 1000 UIDs back for
> further processing or in a worst case scenario 1000 individual requests.
> 
> this will be an issue for several things in Plasma Active, such as the file
> manager. unlike Dolphin which just shows metadata for a given file, the
> Active Files app relies on Nepomuk rather than the filesystem for these
> things and allows filtering by ratings, tags, etc.
> 
> > > - We talked about asynchronous querying. Is it going to happen?
> > 
> > There is a QueryRunnable class which can be used to run queries in another
> > thread. Most backends, do not seem to allow asynchronous queries, so there
> > wasn't a way to run queries asynchronously by default.
> 
> those backends could be run in a thread? iow, put the async/threading as a
> first class feature that the backends must implement. even if it means
> having a thread for execution in the background and queueing requests.
> 
> making every user handle the threading sounds like we’ll have lots of code
> that doesn’t ;)
>

Perhaps. There is always a tradeofff between keeping backend implementations 
simple, and having complex library code.

> > > From my POV, it would be much nicer if you forced a single db 

Re: Nepomuk in 4.13 and beyond

[Vishesh Handa]

On Thursday 12 Dec 2013 23:33:50 Ivan Čukić wrote:
> > for the Plasma Active shell as it currently is, single-store querying
> > might
> > be workable as we tend to keep most of the different resources separated
> > in
> > the UI (though that’s one thing i want to change in future releases, so
> > you
> > can group a set of bookmarks with a given file, e.g.)
> 
> Piggy-backing on Aaron's sub-thread.
> 
> Here's a simpler, yet "funnier" example: I want all files tagged as
> 'Dolphin' from 'KDE development' activity.
> 
> Tags for files are located in one store. Things linked to an activity are in
> another store.
> 
> If I got it right, I'd have to:
> 1 - get a list of things tagged with 'Dolphin'
> 2 - get a list of things linked to 'KDE development' activity
> Intersect them.
> 

If both are sqlite, then it's one query -

select fid from tagRelation, activityRelation where aid = 'activityId' and tid 
= 'TagIdentifier';

http://www.sqlite.org/lang_attach.html

This will also work if tags are in xapian and activities in something else 
since xapian provides ways to filter the query when it is running -

http://xapian.org/docs/postingsource.html

> So, we need to do this manually, in-memory, loading potentially hundreds of
> results in order to return a dozen? While the database would do that in an
> optimized way?
> 
> I do get the problem of some clients desiring sql, and some not (xapian or
> whatever else). We would need a way to bridge those anyhow, so why not
> bridge them in a common place (baloo) instead of relying on each client to
> implement it by themselves.
> 

I'm glad we're on the same page. If you take a look at baloo/src/core/query.h 
there is an addRelation function which would let you do stuff like -

Query q;
q.setType("File");
q.addRelation(TagRelation(Tag("Spiderman"));
q.addRelation(ActivityRelation(someActivity));

it = q.exec();

This isn't currently implemented, but that was the general idea.

> Returning on one-db-to-rule-them-all-but-not-exactly :)
> 
> Baloo could provide the client a choice of the backend database. Not in the
> sense of mysql vs sqlite vs postgresql, but rather of a db type - choose
> SQL, choose whatever-designation-xapian-has, (ignored: JSON, KeyVals, RDF
> :) etc.)
> 
> This way, more complex queries that are limited to stores based on a
> specific db type would be super-fast, while others would be slower, but
> still faster than manual implementations.
> 

I agree.

-- 
Vishesh Handa

Re: Nepomuk in 4.13 and beyond

[Vishesh Handa]

On Friday 13 Dec 2013 15:10:32 Shantanu Tushar Jha wrote:
> Hi Vishesh,
> 
> While we're doing a "better Nepomuk", something that I'll personally love
> improved is real-time[1] resource updates. We disabled resource watcher in
> PMC a long time back because it used to slow down things a *lot*. I'd
> envision something along the lines of signals which would notify the
> resource IDs (or equivalent) that have changed. While the bare minimum
> would be creation/deletion, notifications about changes to metadata will
> rock.
> 

Yes. Better monitoring is something we desperately need. Now that we have 
different stores for each type of data, this will be a lot easier to implement.

I still have to work on a monitoring API for Files. There is one already in 
place for Tags.

-- 
Vishesh Handa

Re: Nepomuk in 4.13 and beyond

[Marco Martin]

On Thursday 12 December 2013, Vishesh Handa wrote:
> On Thursday 12 Dec 2013 19:40:11 Ivan Čukić wrote:
> > > If we all decide to store stuff in sqlite, then it doesn't matter if
> > > they are separate database files or the same one.
> > 
> > I might be missing a few things here, but asking questions is the road to
> > enlightenment :)
> > 
> > - There is no way to query across different stores, which was the main
> > appeal of nepomuk? (I concluded this from the last mail)
> 
> There isn't one. Not right now. I'm open to ideas on how to do something
> like if it is required. I'm slightly skeptical if it actually is required.

- query attachments saved on disk sent by $person?
- tags or activities  associations
- 

> > - When querying, how do I get the properties of the results?
> 
> You don't. You just get the identifier and some text. You can do a
> subsequent fetch job to get additional data.

ouch, if i have to display a lot of results that looks very heavy, and a loot 
of jobs, just a bit worried about that


> > From my POV, it would be much nicer if you forced a single db (as an
> > actual store, not as a cache like nepomuk is for akonadi) on the people,
> > with the option to have a few things runtime defined. It would ease the
> > development and would allow more fun queries which would be optimized
> > unlike the manual client-side joining of different query results.
> 
> But what if one doesn't use SQL for storing data? IMO Xapian is much better
> suited that sqlite's FTS support (or mysql).
> 

Xapian is just for files indexing, right? (and no, file indexing with sqlite 
would blow up in a nuclear explosion;)

what i would see is a central sqlite db with just relations between stuff.
* tag/anything (being file, email, whatever)
* activity/anything
* anything/anything (so explicit relation between contanct and file for 
instance)

that sqlite db makes sense being sqlite since the amount of data in it would 
probably stay pretty limited (mostly relations hand made, anyways around 
hundreds of items max vs the hundred thousands of the file index for instance)

then the actual file metadata, email metadata etc can be stored wherever

is also important having more flexible queries, like sql directly exposed (in 
plasma active i *need* to have group by, that's the reason we used directly 
sparql in some queries)

Cheers,
Marco Martin

Re: Nepomuk in 4.13 and beyond

[Marco Martin]

On Thursday 12 December 2013, Vishesh Handa wrote:

> > what you describe is amazingly similar to the system Wheeler and I came
> > up with during the very first Akademy. if you’re ever interested in what
> > ever became of that, remind me over a coffee/beer sometime and i’ll put
> > on my old-man pants and recount the ol’ days. ;)
> 
> Sure. Plasma sprint.

/me will just drop a name that will give a little tear to the oldies..
Tenor ;)

> Disable Nepomuk (System settings) and install Baloo. It should startup on
> boot, otherwise you can run the baloo_file process.
> 
> Most of the PIM side is already integrated, but the patches still have to
> be pushed. (I'll push them into a clone) I've started working on porting
> Dolphin, but I need to talk with Frank.
> 
> What exactly do you want to integrate?

Most pressing for us is the porting of that nepomuk model in plasma active 
(then depending on how the model may keep external facing api unchanged or not 
may magically port a lot of stuff.. or not)

main things the nepomuk model is used for:
* Activities: showing in the homescreen resources linked to an activity, 
grouped by type
* File browser application:
** show files by type (like all images, all documents..)
** to that, add a filter by tag or by date
** to display tags and dates, we need a group by: to have a kind of tag cloud 
and to quickly compare for instance how many photos were taken in May as 
opposed to April
* SLC: acts of connecting something to an activity, assigning a tag, assigning 
a rating, adding a bookmark (in active bookmarks are stored in nepomuk too)

* Plasma media center: pretty much the same requirements

> > what is the Baloo equivalent of the Nepomuk API currently in kdelibs?
> > (i’ve looked in the ballo repo, it isn’t clear at first glance)
> 
> There isn't a clear Resource API any more. There is a nice query API - take
> a look at baloo/src/core/query.h / term.h. There are some "examples" in
> the autotests directory.

I would be happy even with just a way to have something that makes very easy 
to access even just a variant map of properties (ugh, i guess that tells I'm 
doing way too much javascript lately :p)

Cheers, 
Marco Martin

Re: Nepomuk in 4.13 and beyond

[Aaron J. Seigo]

On Friday, December 13, 2013 12:13:19 Vishesh Handa wrote:
> If you want, we can discuss this over a hangout or irc where there is a
> smaller delay between responses.
> 
> What time would be suitable for everyone?

today before 17:00; this weekend i’m busy, and then next week i’m relatively 
available again.

-- 
Aaron J. Seigo

Review Request 114436: Set WindowModality of all KIO message box to Qt::WindowModal

[Dawit Alemayehu]

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

Review request for kdelibs, David Faure and Frank Reininghaus.


Repository: kdelibs


Description
---

The attached patch changes the WindowModality of all the message/information 
boxes displayed by KIO::JobUiDelegate to Qt::WindowModal instead of 
Qt::ApplicationModal. This prevents a message box in one window from blocking 
all other windows.


Diffs
-

  kio/kio/jobuidelegate.cpp 8534863 

Diff: http://git.reviewboard.kde.org/r/114436/diff/


Testing
---


Thanks,

Dawit Alemayehu

Re: Review Request 114436: Set WindowModality of all KIO message box to Qt::WindowModal

[Frank Reininghaus]

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


Thanks for looking into this, Dawit! I greatly appreciate this effort.


Two questions come to my mind:

1. Why should these dialogs be modal at all? Everything that KIO does is 
asynchronous, so it could very well be that the window isn't even showing the 
directory (where the action took place that triggered the dialog) any more.

2. Since every little change can have unexpected side effects, and the 
"modality" issue is not causing a lot of trouble for users right now (please 
correct me if I'm wrong), maybe this change should better be done in master? 
Currently, the only situation in which a single process can have multiple 
windows that can perform file management actions is that there are two 
Konqueror windows, one of which was opened from the other one with "Open New 
Window", I think (but I might be overlooking some other possibilities).


Some background for people who have not followed the "modality" discussion in 
the past: some time ago, Thomas raised the question why Dolphin is not a 
KUniqueApplication any more. This was done mostly because Strigi made Dolphin 
crash a lot, and it was quite annoying for users to see all their Dolphin 
windows disappear if one of them crashed (this is not a big problem any more), 
but also because it was a bit irritating that KIO dialogs would freeze all 
Dolphin windows. Some more information can be found in these threads:

http://lists.kde.org/?t=13752968312&r=1&w=2
http://lists.kde.org/?t=13753723594&r=1&w=2

- Frank Reininghaus


On Dec. 13, 2013, 1:53 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114436/
> ---
> 
> (Updated Dec. 13, 2013, 1:53 p.m.)
> 
> 
> Review request for kdelibs, David Faure and Frank Reininghaus.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> The attached patch changes the WindowModality of all the message/information 
> boxes displayed by KIO::JobUiDelegate to Qt::WindowModal instead of 
> Qt::ApplicationModal. This prevents a message box in one window from blocking 
> all other windows.
> 
> 
> Diffs
> -
> 
>   kio/kio/jobuidelegate.cpp 8534863 
> 
> Diff: http://git.reviewboard.kde.org/r/114436/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Review Request 114437: Add right click contextmenu for Plasma Components TextField

[Leszek Lesner]

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

Review request for KDE Runtime.


Repository: kde-runtime


Description
---

This adds a right click context menu for PlasmaComponents.TextField which 
allows to cut, copy and paste text. 


Diffs
-

  plasma/declarativeimports/plasmacomponents/qml/TextField.qml 10a3d1f 

Diff: http://git.reviewboard.kde.org/r/114437/diff/


Testing
---


Thanks,

Leszek Lesner

Re: Review Request 114437: Add right click contextmenu for Plasma Components TextField

[Sebastian Kügler]

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


Two comments inline.


plasma/declarativeimports/plasmacomponents/qml/TextField.qml


Use i18n() here



plasma/declarativeimports/plasmacomponents/qml/TextField.qml


i18n() here as well


- Sebastian Kügler


On Dec. 13, 2013, 3:01 p.m., Leszek Lesner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114437/
> ---
> 
> (Updated Dec. 13, 2013, 3:01 p.m.)
> 
> 
> Review request for KDE Runtime.
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> ---
> 
> This adds a right click context menu for PlasmaComponents.TextField which 
> allows to cut, copy and paste text. 
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/TextField.qml 10a3d1f 
> 
> Diff: http://git.reviewboard.kde.org/r/114437/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Leszek Lesner
> 
>

Re: Review Request 114437: Add right click contextmenu for Plasma Components TextField

[Lukáš Tinkl]

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



plasma/declarativeimports/plasmacomponents/qml/TextField.qml


...and here as well :)


- Lukáš Tinkl


On Dec. 13, 2013, 4:01 p.m., Leszek Lesner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114437/
> ---
> 
> (Updated Dec. 13, 2013, 4:01 p.m.)
> 
> 
> Review request for KDE Runtime.
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> ---
> 
> This adds a right click context menu for PlasmaComponents.TextField which 
> allows to cut, copy and paste text. 
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/TextField.qml 10a3d1f 
> 
> Diff: http://git.reviewboard.kde.org/r/114437/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Leszek Lesner
> 
>

Re: Review Request 114436: Set WindowModality of all KIO message box to Qt::WindowModal

[Thomas Lübking]

> On Dec. 13, 2013, 2:27 p.m., Frank Reininghaus wrote:
> > Thanks for looking into this, Dawit! I greatly appreciate this effort.
> > 
> > 
> > Two questions come to my mind:
> > 
> > 1. Why should these dialogs be modal at all? Everything that KIO does is 
> > asynchronous, so it could very well be that the window isn't even showing 
> > the directory (where the action took place that triggered the dialog) any 
> > more.
> > 
> > 2. Since every little change can have unexpected side effects, and the 
> > "modality" issue is not causing a lot of trouble for users right now 
> > (please correct me if I'm wrong), maybe this change should better be done 
> > in master? Currently, the only situation in which a single process can have 
> > multiple windows that can perform file management actions is that there are 
> > two Konqueror windows, one of which was opened from the other one with 
> > "Open New Window", I think (but I might be overlooking some other 
> > possibilities).
> > 
> > 
> > Some background for people who have not followed the "modality" discussion 
> > in the past: some time ago, Thomas raised the question why Dolphin is not a 
> > KUniqueApplication any more. This was done mostly because Strigi made 
> > Dolphin crash a lot, and it was quite annoying for users to see all their 
> > Dolphin windows disappear if one of them crashed (this is not a big problem 
> > any more), but also because it was a bit irritating that KIO dialogs would 
> > freeze all Dolphin windows. Some more information can be found in these 
> > threads:
> > 
> > http://lists.kde.org/?t=13752968312&r=1&w=2
> > http://lists.kde.org/?t=13753723594&r=1&w=2

> 1. Why should these dialogs be modal at all?

Unless anybody has a better explanation I assume it was done because of either
a) the wrong assumption that "modal" equals "transient"
b) the assumption of (a) actually may hold on some systems?

A modal window is used if sequential action is mandatory, eg. if you open a 
file you can not edit it before you opened it - the modal dialog makes sense to 
enforce the workflow and assert() it in the code.

This is obviously not the case here:
the system MUST be prepared to filesystem changes during the nested eventloop 
of the modal dilaog, eg. while the dialog asks "do you really want to delete 
foo/bar.txt" this could just happen in another dolphin window, in konsole, VT1 
or through a script or cron job.


On top of this, I do not even think the dialog should be transient.

Eg. I often start a longer (network, crap USB stick) copy job and close dolphin 
immediately.
Popping up questions (override) arrive for the copy job and not the causing 
process (long closed dolphin)

The user must get aware that this action is currently halted and requires 
interaction to continue, but that isn't related to a particular other window.
Some "system interaction spot" would be nice but it had to significantly differ 
from the common "i don't care" notification that pops up because phonon thinks 
it lost a resource or so.
Alternatively the process indicator in the notification area could just start 
blinking or show a "interaction required!" message/icon/whatsoever.

This is however probably beyond KDE4.

The fallback (non-plasma context) solution could simply be a "keep above on all 
desktops" dialog (it doesn't have to get the focus, but must show up visible) 
what might be a usable approach even for KDE4


- Thomas


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


On Dec. 13, 2013, 1:53 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114436/
> ---
> 
> (Updated Dec. 13, 2013, 1:53 p.m.)
> 
> 
> Review request for kdelibs, David Faure and Frank Reininghaus.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> The attached patch changes the WindowModality of all the message/information 
> boxes displayed by KIO::JobUiDelegate to Qt::WindowModal instead of 
> Qt::ApplicationModal. This prevents a message box in one window from blocking 
> all other windows.
> 
> 
> Diffs
> -
> 
>   kio/kio/jobuidelegate.cpp 8534863 
> 
> Diff: http://git.reviewboard.kde.org/r/114436/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Re: Review Request 114437: Add right click contextmenu for Plasma Components TextField

[Leszek Lesner]

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

(Updated Dec. 13, 2013, 3:35 p.m.)


Review request for KDE Runtime.


Changes
---

Updated the diff to select text in textinput right after calling open upon the 
contextmenu.


Repository: kde-runtime


Description
---

This adds a right click context menu for PlasmaComponents.TextField which 
allows to cut, copy and paste text. 


Diffs (updated)
-

  plasma/declarativeimports/plasmacomponents/qml/TextField.qml 10a3d1f 

Diff: http://git.reviewboard.kde.org/r/114437/diff/


Testing
---


Thanks,

Leszek Lesner

Re: Review Request 114437: Add right click contextmenu for Plasma Components TextField

[Leszek Lesner]

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

(Updated Dec. 13, 2013, 3:37 p.m.)


Review request for KDE Runtime.


Changes
---

Use i18n() instead of qsTr()


Repository: kde-runtime


Description
---

This adds a right click context menu for PlasmaComponents.TextField which 
allows to cut, copy and paste text. 


Diffs (updated)
-

  plasma/declarativeimports/plasmacomponents/qml/TextField.qml 10a3d1f 

Diff: http://git.reviewboard.kde.org/r/114437/diff/


Testing
---


Thanks,

Leszek Lesner

Re: Review Request 114437: Add right click contextmenu for Plasma Components TextField

[Burkhard Lück]

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


Where is the message extraction for these i18n() ?

- Burkhard Lück


On Dec. 13, 2013, 3:37 p.m., Leszek Lesner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114437/
> ---
> 
> (Updated Dec. 13, 2013, 3:37 p.m.)
> 
> 
> Review request for KDE Runtime.
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> ---
> 
> This adds a right click context menu for PlasmaComponents.TextField which 
> allows to cut, copy and paste text. 
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/TextField.qml 10a3d1f 
> 
> Diff: http://git.reviewboard.kde.org/r/114437/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Leszek Lesner
> 
>

Re: Review Request 114436: Set WindowModality of all KIO message box to Qt::WindowModal

[Kai Uwe Broulik]

> On Dec. 13, 2013, 2:27 p.m., Frank Reininghaus wrote:
> > Thanks for looking into this, Dawit! I greatly appreciate this effort.
> > 
> > 
> > Two questions come to my mind:
> > 
> > 1. Why should these dialogs be modal at all? Everything that KIO does is 
> > asynchronous, so it could very well be that the window isn't even showing 
> > the directory (where the action took place that triggered the dialog) any 
> > more.
> > 
> > 2. Since every little change can have unexpected side effects, and the 
> > "modality" issue is not causing a lot of trouble for users right now 
> > (please correct me if I'm wrong), maybe this change should better be done 
> > in master? Currently, the only situation in which a single process can have 
> > multiple windows that can perform file management actions is that there are 
> > two Konqueror windows, one of which was opened from the other one with 
> > "Open New Window", I think (but I might be overlooking some other 
> > possibilities).
> > 
> > 
> > Some background for people who have not followed the "modality" discussion 
> > in the past: some time ago, Thomas raised the question why Dolphin is not a 
> > KUniqueApplication any more. This was done mostly because Strigi made 
> > Dolphin crash a lot, and it was quite annoying for users to see all their 
> > Dolphin windows disappear if one of them crashed (this is not a big problem 
> > any more), but also because it was a bit irritating that KIO dialogs would 
> > freeze all Dolphin windows. Some more information can be found in these 
> > threads:
> > 
> > http://lists.kde.org/?t=13752968312&r=1&w=2
> > http://lists.kde.org/?t=13753723594&r=1&w=2
> 
> Thomas Lübking wrote:
> > 1. Why should these dialogs be modal at all?
> 
> Unless anybody has a better explanation I assume it was done because of 
> either
> a) the wrong assumption that "modal" equals "transient"
> b) the assumption of (a) actually may hold on some systems?
> 
> A modal window is used if sequential action is mandatory, eg. if you open 
> a file you can not edit it before you opened it - the modal dialog makes 
> sense to enforce the workflow and assert() it in the code.
> 
> This is obviously not the case here:
> the system MUST be prepared to filesystem changes during the nested 
> eventloop of the modal dilaog, eg. while the dialog asks "do you really want 
> to delete foo/bar.txt" this could just happen in another dolphin window, in 
> konsole, VT1 or through a script or cron job.
> 
> 
> On top of this, I do not even think the dialog should be transient.
> 
> Eg. I often start a longer (network, crap USB stick) copy job and close 
> dolphin immediately.
> Popping up questions (override) arrive for the copy job and not the 
> causing process (long closed dolphin)
> 
> The user must get aware that this action is currently halted and requires 
> interaction to continue, but that isn't related to a particular other window.
> Some "system interaction spot" would be nice but it had to significantly 
> differ from the common "i don't care" notification that pops up because 
> phonon thinks it lost a resource or so.
> Alternatively the process indicator in the notification area could just 
> start blinking or show a "interaction required!" message/icon/whatsoever.
> 
> This is however probably beyond KDE4.
> 
> The fallback (non-plasma context) solution could simply be a "keep above 
> on all desktops" dialog (it doesn't have to get the focus, but must show up 
> visible) what might be a usable approach even for KDE4

Unfortunately that [1] never made it to a final state :-/

[1] http://en.munknex.net/2012/06/new-kde-copy-dialog-first-preview.html


- Kai Uwe


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


On Dec. 13, 2013, 1:53 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114436/
> ---
> 
> (Updated Dec. 13, 2013, 1:53 p.m.)
> 
> 
> Review request for kdelibs, David Faure and Frank Reininghaus.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> The attached patch changes the WindowModality of all the message/information 
> boxes displayed by KIO::JobUiDelegate to Qt::WindowModal instead of 
> Qt::ApplicationModal. This prevents a message box in one window from blocking 
> all other windows.
> 
> 
> Diffs
> -
> 
>   kio/kio/jobuidelegate.cpp 8534863 
> 
> Diff: http://git.reviewboard.kde.org/r/114436/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Re: Nepomuk in 4.13 and beyond

[Ivan Čukić]

> today before 17:00; this weekend i’m busy, and then next week i’m relatively
> available again.

Monday or later for me.


-- 
Science gathers knowledge faster than society gathers wisdom.
  -- Isaac Asimov

Re: Nepomuk in 4.13 and beyond

[Ivan Čukić]

> If both are sqlite, then it's one query -
> 
> select fid from tagRelation, activityRelation where aid = 'activityId' and
> tid = 'TagIdentifier';

Now your talkin' 

This looks nice
- It needs to be abstracted into a proper api that can understand that those 
are separate dbs. (this removes my problem regarding one-database - since the 
underlying engine can consider multiple databases to be a single one)
- Raises a potential problem if it turns out that sqlite is not sufficient for 
our use-cases (which I hope will not happen)

> This will also work if tags are in xapian and activities in something else
> since xapian provides ways to filter the query when it is running -
> 
> http://xapian.org/docs/postingsource.html

I've seen that xapian can be used to index stuff in other databases. Any use 
for that? Or is it better to keep them separate.


> I'm glad we're on the same page. If you take a look at
> baloo/src/core/query.h there is an addRelation function which would let you
> do stuff like -

At the moment, then, the main problem that remains is that queries are not 
able to return anything except a list of results (such as result properties). 
Eliminating round-trips and all.

One of Marco's greatest annoyances with old kactivities API was exactly that - 
a method that returns a list of activities, and methods to get various 
properties for an activity. The service is now able to dump everything you 
want in one chunk.

And, almost forgot, async api.

It might be nice to talk about it at Tokamak, though it might also be a bit 
too late?

Cheers