Re: http://techbase.kde.org/Development/Review_Board looks terribly complicated

[Ben Cooksley]

On Mon, Dec 16, 2013 at 3:25 PM, Harald Sitter  wrote:

> On Mon, Dec 16, 2013 at 12:29 AM, Albert Astals Cid  wrote:
> > adding a section before all that huge lists of hard
> > stuff just saying "You can code, do a git diff and upload the diff in the
> > webpage".
>
> oh my god, yes, please!
>

Full +1, in my use of Reviewboard I have always followed that same method.


>
> HS
>

Regards,
Ben

Re: http://techbase.kde.org/Development/Review_Board looks terribly complicated

[Harald Sitter]

On Mon, Dec 16, 2013 at 12:29 AM, Albert Astals Cid  wrote:
> adding a section before all that huge lists of hard
> stuff just saying "You can code, do a git diff and upload the diff in the
> webpage".

oh my god, yes, please!

HS

Re: Review Request 114484: Fix KMainWindow size management, esp. on asymmetric multiscreens

[Thomas Lübking]

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



kdeui/widgets/kmainwindow.cpp


i can not recall this would have ever been NULL for me, but i cannot say 
anything about Windows or MacOS either



kdeui/widgets/kmainwindow.cpp


This may have been the case, but is not.
It would also have had any impact on the unspecified special handling in 
KWin


- Thomas Lübking


On Dec. 15, 2013, 11:28 p.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114484/
> ---
> 
> (Updated Dec. 15, 2013, 11:28 p.m.)
> 
> 
> Review request for kdelibs, Christoph Feck and Martin Gräßlin.
> 
> 
> Bugs: 286146, 317760 and 324957
> http://bugs.kde.org/show_bug.cgi?id=286146
> http://bugs.kde.org/show_bug.cgi?id=317760
> http://bugs.kde.org/show_bug.cgi?id=324957
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Due to the many patches arriving to kdelibs, i just thought to give it a try 
> ;-)
> 
> Notice that i did not align the non unix/x11 preproc branches, but will in 
> case it's accepted.
> 
> 
> tl; dr
> ==
> 
> situation now:
> --
> - on multiscreen setups with different sizes
>   * KMainWindow may open with the "wrong" size (286146)
>   * KMainWindow may open on the "wrong" (not active) screen
> - maximized KMainWindow re-opens maximized, but lost its unmaximized state
> - windows that randomly cover the maximum width of height will falsely open 
> maximized in that direction (317760)
> 
> situation after:
> 
> - on multiscreen setups with different sizes
>   * KMainWindow will open with the last size
>   * KMainWindow will (usually, see details) open on the active screen
> - maximized KMainWindow re-opens maximized, unmaximizing will restore the 
> previous maximized size
> - we should be able to remove the kludge that causes bug #317760 from KWin 
> (KMainWindow is explicitly referenced there and the behavior is unspecified 
> and undocumented)
> 
> 
> --
> 
> En Detail
> =
> 
> I started out by seeking a fix for bug #286146
> The issue here is that KMainWindow handles the size in relation to the 
> current screen resolution.
> The "current screen resolution" is the one of the screen where the window is.
> This happens *before* the WM places the window (eventually selecting another 
> screen)
> If the screen changes or if you just closed it on the other screen before, 
> you'll not get the size you'd expect (because it had a different size when 
> you closed it and/or even does not match the size stored for the screen it 
> opened on)
> 
> In addition to that, the size may be "too big" for the active screen (in 
> which case kwin will place it on the fitting screen rather than dropping 
> borders)
> 
> There're 5 possible solutions to this:
> 1. KWin does not alter the screen (ie. move the window to the "active" 
> screen) for the window
> 2. KMainWindow knows the target screen
> 3. KMainWindow anticipates the target screen
> 4. KMainWindow restores its size *after* being mapped and placed by the WM
> 5. KMainWindow treats the combined screens of the multiscreen as one for the 
> size management
> 
> ad 1)
> No. :) Plus, there'd be no guarantee for the behavior on other WMs
> 
> ad 2)
> Unfortunately NETWM is completely multiscreen unaware, so there's no protocol 
> in place, so it could be a KMainWindow & KWin related "solution" only
> 
> ad 3)
> KMainWindow would have to read kwinrc settings, plus same issue again: 
> KMainWindow & KWin related "solution" only
> 
> ad 4)
> Possible, but will cause visible flicker (user sees the window mapped with 
> original size and then resized) - we might hide that in the compositor, but 
> that would delay all window showing and be a KWin only solution again.
> 
> ad 5)
> proposed solution =)
> This is acceptable if users rather care about the size in relation to the 
> window than to the screen ("window shall open at size that I left behind, no 
> matter on which screen") and we can assume WMs to keep windows in workarea 
> bounds (like KWin does and a diminished issue to to the changed handling of 
> maximized windows, see next)
> 
> 
> "Unfortunately" that fix trapped me into bug #317760 on steroids.
> So far the maximization state was stored by storing "screenSize + 1", what, 
> for the change and a multiscreen setup like [1024x768+0+0; 1920x1200+1024+0] 
> means that the (formerly maximized on the XGA screen) window was restored to 
> 2944+1200, what KWin would thankfully punch into 

http://techbase.kde.org/Development/Review_Board looks terribly complicated

[Albert Astals Cid]

Hi, looking at http://techbase.kde.org/Development/Review_Board I wonder how 
any of our newbies has ever been able to push a patch to reviewboard if we're 
suggesting to use that amazing number of hard things to do.

Does anyone object to me adding a section before all that huge lists of hard 
stuff just saying "You can code, do a git diff and upload the diff in the 
webpage".

I've been doing that forever and even if it may not be "the righteous git way" 
I'm totally happy with it and IMHO it's much more newbie friendly.

Comments?

Albert

Review Request 114484: Fix KMainWindow size management, esp. on asymmetric multiscreens

[Thomas Lübking]

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

Review request for kdelibs, Christoph Feck and Martin Gräßlin.


Bugs: 286146, 317760 and 324957
http://bugs.kde.org/show_bug.cgi?id=286146
http://bugs.kde.org/show_bug.cgi?id=317760
http://bugs.kde.org/show_bug.cgi?id=324957


Repository: kdelibs


Description
---

Due to the many patches arriving to kdelibs, i just thought to give it a try ;-)

Notice that i did not align the non unix/x11 preproc branches, but will in case 
it's accepted.


tl; dr
==

situation now:
--
- on multiscreen setups with different sizes
  * KMainWindow may open with the "wrong" size (286146)
  * KMainWindow may open on the "wrong" (not active) screen
- maximized KMainWindow re-opens maximized, but lost its unmaximized state
- windows that randomly cover the maximum width of height will falsely open 
maximized in that direction (317760)

situation after:

- on multiscreen setups with different sizes
  * KMainWindow will open with the last size
  * KMainWindow will (usually, see details) open on the active screen
- maximized KMainWindow re-opens maximized, unmaximizing will restore the 
previous maximized size
- we should be able to remove the kludge that causes bug #317760 from KWin 
(KMainWindow is explicitly referenced there and the behavior is unspecified and 
undocumented)


--

En Detail
=

I started out by seeking a fix for bug #286146
The issue here is that KMainWindow handles the size in relation to the current 
screen resolution.
The "current screen resolution" is the one of the screen where the window is.
This happens *before* the WM places the window (eventually selecting another 
screen)
If the screen changes or if you just closed it on the other screen before, 
you'll not get the size you'd expect (because it had a different size when you 
closed it and/or even does not match the size stored for the screen it opened 
on)

In addition to that, the size may be "too big" for the active screen (in which 
case kwin will place it on the fitting screen rather than dropping borders)

There're 5 possible solutions to this:
1. KWin does not alter the screen (ie. move the window to the "active" screen) 
for the window
2. KMainWindow knows the target screen
3. KMainWindow anticipates the target screen
4. KMainWindow restores its size *after* being mapped and placed by the WM
5. KMainWindow treats the combined screens of the multiscreen as one for the 
size management

ad 1)
No. :) Plus, there'd be no guarantee for the behavior on other WMs

ad 2)
Unfortunately NETWM is completely multiscreen unaware, so there's no protocol 
in place, so it could be a KMainWindow & KWin related "solution" only

ad 3)
KMainWindow would have to read kwinrc settings, plus same issue again: 
KMainWindow & KWin related "solution" only

ad 4)
Possible, but will cause visible flicker (user sees the window mapped with 
original size and then resized) - we might hide that in the compositor, but 
that would delay all window showing and be a KWin only solution again.

ad 5)
proposed solution =)
This is acceptable if users rather care about the size in relation to the 
window than to the screen ("window shall open at size that I left behind, no 
matter on which screen") and we can assume WMs to keep windows in workarea 
bounds (like KWin does and a diminished issue to to the changed handling of 
maximized windows, see next)


"Unfortunately" that fix trapped me into bug #317760 on steroids.
So far the maximization state was stored by storing "screenSize + 1", what, for 
the change and a multiscreen setup like [1024x768+0+0; 1920x1200+1024+0] means 
that the (formerly maximized on the XGA screen) window was restored to 
2944+1200, what KWin would thankfully punch into 1920x1200 and place it on the 
WUXGA screen, so this approach had to go.

Using "screenSize(n) + 1" was equally not an option since that size could no 
longer be reliably matched against anything (the size was read from the 
combined screen size and chacking the available screens could fail because a 
window could legally be closed at 1025x769 on the WUXGA screen)

The cleanest option would have been to store the state in an additional key 
(see bug #51571, laptop + Tv became more popular since than, I guess) but due 
to the kdelibs semi(?)-frozen state i simply used the sign for this purpose.
-> One word and there'll be an extra key (wile unless anything else reads this, 
the negative values are pretty "safe")

Since the size is no longer used to store the state, it was possible to just 
preserve the unmaximized size and restore it alongside the maximization state.

And since the "maximized is screenSize + 1" kludge is gone in KMainWindow, we 
could remove it from KWin in addition.

T

Review Request 114481: khtml/ecma: Implement canvas2d font, measureText and a basic fillText

[Bernd Buschinski]

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

Review request for kdelibs.


Repository: kdelibs


Description
---

khtml/ecma: Implement canvas2d font, measureText and a basic fillText

While font and measureText are complet, filltext is really just a bare basic 
implementation.
But still, thats what is used the most and it does draw Text :)


Diffs
-

  khtml/ecma/kjs_context2d.h 481404e 
  khtml/ecma/kjs_context2d.cpp bbdba8f 
  khtml/html/html_canvasimpl.h e46ed8f 
  khtml/html/html_canvasimpl.cpp 53e0f22 

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


Testing
---

Passes all font/measureText/fillText canvas tests on 
http://philip.html5.org/tests/canvas/suite/tests/
(for what we support for now, which (again) is just a bare basic for fillText)


Thanks,

Bernd Buschinski

Re: Review Request 114479: Select the newly created bookmark folder as the current item

[Dawit Alemayehu]

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

(Updated Dec. 15, 2013, 4:40 p.m.)


Review request for kdelibs and David Faure.


Bugs: 152158
http://bugs.kde.org/show_bug.cgi?id=152158


Repository: kdelibs


Description
---

When a user creates a new bookmark folder in the Add Bookmark dialog, make it 
the current selected item.


Diffs
-

  kio/bookmarks/kbookmarkdialog.cc 713ceff 

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


Testing
---


File Attachments (updated)


Add new folder w/o patch
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/12/15/1be1b4c9-eddd-43cf-b3fa-18cc0a44b212__before.png
Add new folder w/ patch
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/12/15/353b3c50-ccc8-4390-9d76-a9f85a703987__after.png


Thanks,

Dawit Alemayehu

Review Request 114479: Select the newly created bookmark folder as the current item

[Dawit Alemayehu]

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

Review request for kdelibs and David Faure.


Bugs: 152158
http://bugs.kde.org/show_bug.cgi?id=152158


Repository: kdelibs


Description
---

When a user creates a new bookmark folder in the Add Bookmark dialog, make it 
the current selected item.


Diffs
-

  kio/bookmarks/kbookmarkdialog.cc 713ceff 

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


Testing
---


Thanks,

Dawit Alemayehu

Review Request 114473: Change modality of dialog in KRun::displayOpenWithDialog to Qt::WindowModal

[Dawit Alemayehu]

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

Review request for kdelibs and David Faure.


Bugs: 153421
http://bugs.kde.org/show_bug.cgi?id=153421


Repository: kdelibs


Description
---

The attached patch changes the KOpenWith dialog in KRun::displayOpenWithDialog 
from blocking Konqueror windows when a user clicks on OpenWith in the context 
menu or unknown file in the Dolphin part.


Diffs
-

  kio/kio/krun.cpp ad5656e 

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


Testing
---


Thanks,

Dawit Alemayehu

Re: Nepomuk in 4.13 and beyond

[Vishesh Handa]

On Saturday 14 Dec 2013 21:26:35 Ingo Klöcker wrote:
> 
> Hmm, I would love to tag my email (using filters) just like Google Mail
> does so that I can stop filtering my email into folders and I can start
> using "tag folders". This would result in hundreds of thousands of
> relations tag/email, wouldn't it?
> 

We talked about this during the PIM Sprint and decided that the best way to 
store tags for PIM data would be in Akonadi. That way the tags could also be 
saved on the corresponding backend (IMAP, Kolab, etc) and they would be 
synchronized.

Additionally, this would also be compatible would other popular clients such 
as Thunderbird [1][2]

The TagRelation was a proof of concept of global tagging which I would like to 
remove. We're going to be discussing this on Monday after the Plasma Hangout.

-- 
Vishesh Handa

[1] http://kb.mozillazine.org/Tags
[2] https://wiki.mozilla.org/Thunderbird2:Tags

signature.asc
Description: This is a digitally signed message part.

Review Request 114472: kjs: Implement ES6 Number parseInt, parseFloat

[Bernd Buschinski]

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

Review request for kdelibs.


Repository: kdelibs


Description
---

kjs: Implement ES6 Number parseInt, parseFloat

NOTE: unlike the other new ES6 Number function these two MUST behave the same 
as the global parseInt/parseFloat.
The explicit number type check is only valid for the other functions, not for 
parseInt/parseFloat and therefor was moved to the functions.


Diffs
-

  kjs/function.h 17958ab 
  kjs/function.cpp 1102208 
  kjs/number_object.h 634c642 
  kjs/number_object.cpp c284746 

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


Testing
---


Thanks,

Bernd Buschinski

Re: Review Request 114464: kjs: Implement ES6 Number isFinite, isInteger, isSafeInteger, isNaN and add MAX_SAFE_INTEGER, MIN_SAFE_INTEGER constants

[Bernd Buschinski]

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

(Updated Dec. 15, 2013, 10:07 a.m.)


Review request for kdelibs.


Changes
---

- minor comment fix


Repository: kdelibs


Description
---

kjs: Implement ES6 Number isFinite, isInteger, isSafeInteger, isNaN and add 
MAX_SAFE_INTEGER, MIN_SAFE_INTEGER constants


Diffs (updated)
-

  kjs/number_object.h 634c642 
  kjs/number_object.cpp c284746 

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


Testing
---


Thanks,

Bernd Buschinski

Re: Nepomuk in 4.13 and beyond

[Simeon Bird]

> Could you please enumerate what all that involves? From what I know there is -
> 
> 1. Metadata model for running queries
> 2. Timeline based stuff - again, queries
> 3. Showing File metadata - There is a File class and a FileFetchJob
> 4. File ratings/comments - There is no API right now as I haven't decided how 
> to store them. Simeon (an awesome Nepomuk contributor) had the idea of 
> storing 
> them as extended attributes. I still need to investigate more, but it seems 
> like a good idea.
> 5. Tags - read below.
> 
>> how are tags related to data in different stores?
> 
> The initial idea was to have a different TagStore which stores information 
> about tags such as their name, color, icon, etc. Additionally there would be 
> a 
> TagRelation class which connects anything with a tag.
> 
> Have a look at baloo/src/tags/. The code has a large number of unit tests.
> 
> That being said, during the PIM Sprint we established that we want server 
> side 
> tags w.r.t emails and other PIM data. This means two different ways of 
> accessing tags. I was thinking of throwing away the concept of tagging 
> anything, and only allow tagging of files. This way we could store the tag 
> metadata in the extended attributes for a file. From what I hear, Mac also 
> stores tags as extended attributes.

(Just to extend this idea a little for the record)

What mac does is indeed to store tags in an xattr. On fat, which does
not support xattrs, it creates a hidden file, called something like
.__filename_xattr (I forget the exact name) to store the xattr data.

So if we were to do this and support removable media we would need to
alter kdelibs to support this or a similar way of storing xattrs
somehow. Is that doable or sensible?

Advantages I can see are:

- it helps a lot with all the file watching stuff; we would no longer
have to instantly install watches all over removable media, with the
attendant problems.
- cp -a would preserve metadata, while cp would not, which makes sense
- it is the only way I can see of cleanly fixing bug 326442, which
happens because KSaveFile does a create/unlink/rename, and nepomuk sees
the unlink and deletes the metadata.
- Using dolphin or another kdelibs based filemanager to move files while
the file watcher isn't running would no longer lose tags.

[The flipside to this one is that using, eg, thunar when the search
indexer *is* running to transfer files to an external drive could lose
tags when it would not have before, but this could in principle be fixed
by submitting a patch to thunar, etc.]

There could be a secondary goal of being compatible with the mac
implementation, which might or might not be worth it.

Simeon

Re: Nepomuk in 4.13 and beyond

[Shantanu Tushar Jha]

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.

Cheers!



On Fri, Dec 13, 2013 at 12:40 AM, 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.
>
> > - 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.
>
> This is however just the generic Query API, if required we can design
> better
> APIs for something you have in mind. I have some specialized APIs for
> querying
> PIM data which are more useful in certain cases.
>
> >
> > When asking for the attachments sent by Alice, I don't care only about
> the
> > id, title and the icon of the result. I'd like to get the mimetype, size
> > etc. (for example, to group the results), or for further processing if I
> > have no desire to show the results directly to the user. Can I retrieve
> > those with baloo api? Do I need to make separate queries for those?
> >
>
> Attachments are a strange corner case, in Akonadi, where it isn't really a
> file
> since it does not have a url, and is not dereference-able. For normal
> files,
> you currently just get the url.
>
> >
> > The Result class looks like it was tailored only for displaying the
> results
> > to the user - KRunner style (design of it all looks quite similar to
> > KRunner to be honest).
> >
>
> It was designed for Runners, Dolphin, and Email Search. It wasn't designed
> to
> be a Nepomuk Query API replacement.
>
> > - 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.
>
> > I see a lot of KJobs for altering stuff, but Query and ResultIterator do
> not
> > look async.
> >
> > Just imagine a store that wants to query currently open windows (via dbus
> > connection to kwin), or currently open documents for an activity
> (requires
> > connection to both kamd and kwin). It can not be done sanely in a
> > synchronous way. One of the main things in libkactivities was to make
> > everything be totally async.
> >
>
> I'm open to suggestions on how to implement queries in an async manner.
>
> > - Database integration
> >
> > When we talked about the nepomuk successor at Akademy, one of the main
> > benefits I saw at the time was the possibility to integrate all dbs into
> one
> > (and shut up all the people who complain we like dbs too much :) ). Baloo
> > seems to go out of its way to accommodate the fact that everybody is
> using
> > different things (be it mysql, embedded mysql, sqlite, plain text etc.).
> >
> > 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).
>
> I agree with you on the fun query bit, but I'm skeptical if those "fun
> queries" are genuinely required. How about we list down the use cases and
> then
> see?
>
> When planning Baloo, I've mostly taken a look at PIM, Dolphin, KRunner (and
> Milou), PMC, and KPeople. Perhaps something was missed?
>
> >
> >
> > Cheerio,
> > Ivan.
>
> --
> Vishesh Handa
>



-- 
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com