Re: Review Request: Define tooltips for kdeui standard actions

[David Jarvie]

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


Good idea! A couple of quick comments follow.


kdeui/actions/kstandardaction_p.h


"Discard" might be a bit more understandable and less technical term.



kdeui/actions/kstandardaction_p.h


I doubt whether "elements" will necessarily be understandable to a non-tech 
user in all circumstances, especially when it's just a block of text.



kdeui/actions/kstandardaction_p.h


"Elements" is too technical a term to necessarily be understandable to a 
non-tech user in all circumstances, especially when it just refers to a block 
of text.


- David Jarvie


On May 13, 2012, 10:08 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104934/
> ---
> 
> (Updated May 13, 2012, 10:08 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> Attached patch tries to define tooltips for most of kdeui standard actions. 
> The goal of this change is to try to bring value to the tooltips of toolbar 
> buttons, instead of simply repeating the button text (I wrote a blog post 
> about this: 
> http://agateau.com/2012/05/11/common-user-interface-mistakes-in-kde-applications-part-5-big-toolbars/
>  ).
> 
> I tried to come up with tooltips which would remain generic enough in a wide 
> range of contexts, but couldn't find generic-enough tooltips for every 
> actions. In this case I left the tooltip empty, which cause QToolButton to 
> use the action text as tooltip, as before.
> 
> If you have suggestions for the missing tooltips or corrections to the 
> tooltips I came up with (I am not a native english speaker), please comment.
> 
> 
> Diffs
> -
> 
>   kdeui/actions/kstandardaction.cpp 2312cc1 
>   kdeui/actions/kstandardaction_p.h f6e6ae7 
>   kdeui/actions/ktogglefullscreenaction.cpp 8d03d6e 
> 
> Diff: http://git.reviewboard.kde.org/r/104934/diff/
> 
> 
> Testing
> ---
> 
> Tested with a few KDE applications: KWrite, Kate, Dolphin, Gwenview. Checked 
> improved tooltips are shown and code still falls back to action text if no 
> tooltip is defined.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Review Request: Define tooltips for kdeui standard actions

[Aurélien Gâteau]

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

Review request for kdelibs.


Description
---

Attached patch tries to define tooltips for most of kdeui standard actions. The 
goal of this change is to try to bring value to the tooltips of toolbar 
buttons, instead of simply repeating the button text (I wrote a blog post about 
this: 
http://agateau.com/2012/05/11/common-user-interface-mistakes-in-kde-applications-part-5-big-toolbars/
 ).

I tried to come up with tooltips which would remain generic enough in a wide 
range of contexts, but couldn't find generic-enough tooltips for every actions. 
In this case I left the tooltip empty, which cause QToolButton to use the 
action text as tooltip, as before.

If you have suggestions for the missing tooltips or corrections to the tooltips 
I came up with (I am not a native english speaker), please comment.


Diffs
-

  kdeui/actions/kstandardaction.cpp 2312cc1 
  kdeui/actions/kstandardaction_p.h f6e6ae7 
  kdeui/actions/ktogglefullscreenaction.cpp 8d03d6e 

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


Testing
---

Tested with a few KDE applications: KWrite, Kate, Dolphin, Gwenview. Checked 
improved tooltips are shown and code still falls back to action text if no 
tooltip is defined.


Thanks,

Aurélien Gâteau

Re: kio and frameworks 5

[Ben Martin]

On Fri, 2012-05-11 at 21:33 +0100, Casper Clemence wrote:
...
> 
> The discussions is this "what part should libferris take in the
> refresh of KIO in KDE Frameworks 5?"
> 
> 
> Ben Martin really should be involved in any discussion of a redesign
> at the very least. He clearly has put a lot of work and thought into
> virtual filesystems and has created something quite unique.

Thank you Casper for all these kind words! 

I am very happy to discuss VFS tech and would be delighted if I could
help with a refresh of KIO. Even if only at the level of contributing
some of the ideas and designs I've come up with over the lifetime of
libferris.

A few ideas from libferris which might be useful, to kick off potential
discussions;

* Using the extended attribute (EA) interface to provide access to all
metadata. Schemas offered for all metadata (fwiw, I used xsd with
extensions in ferris). With these two, one can show any metadata in
directory listings and with schema, can sort the columns correctly. The
schema is also very handy for index/search on data to allow correct
resolution of range queries.

  It can be handy to have access to the ctime, atime, and mtime as
columns in a file manager depending on circumstance. Also, I have found
decorator EA useful, so mtime is the time_t as an int, but mtime-display
is the modification time in a user configurable human readable string
format. The file manager is then free to sort on "mtime" when I click
the "mtime-display" header and I get what I want, readable content
sorted in the correct order.

* With an emphasis on EA as above, the filesystem model becomes much
closer to a virtual XML DOM. With xpath/xquery this can be a useful API
for data access.

* Hookup between RDF and EA. One of the backing plugins for EA in
libferris is a soprano one. This allows 
$ echo 5 > /something/cool.txt@rating
So users and developers don't have to care about RDF/SPARQL for
everybody to reap it's benefits. An added benefit of RDF in this case is
that EA can be attached to any VFS object, be it a flickr photo or a
tuple in a database.

* More to come... is this seen as a useful discussion?

Unfortunately I won't be at Akademy, largely due to my distance from the
event. So quick fire feature exchange over beer is off the table, so to
speak :/

Feel free to list some ideas which are cool from the KIO world too.
Perhaps this can be a useful thread for all VFS hackers...



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

Re: kio and frameworks 5

[Ben Martin]

On Sun, 2012-05-13 at 12:58 +0200, David Faure wrote:
> On Sunday 13 May 2012 11:32:46 Casper Clemence wrote:
> > * it mounts lots more than an ordinary VFS - including XML documents (so
> > the tree of the document can be browsed), databases, X (so that window
> > position and size for example can be read and modified as if they were data
> > in the filesystem), web browser bookmarks...
> > .. all of which leads to the "uniform method of access" I mentioned where
> > all sorts of document data, document structure and metadata becomes
> > available in a a uniform way.
> 
> All this sounds synchronous (the data is always available right away).
> So it probably makes sense as a kioslave (so that all applications can access 
> all of the above via KIO API), not as a replacement for KIO (which has to 
> provide an asynchronous way of accessing network protocols).
> 

The initial API was designed around std::iostreams for both content and
metadata (extended attributes). Over time support was added for running
the various metadata plugins in their own processes etc, and most
recently some work was done on a REST API which would likely be the most
useful for bolting libferris in as a kioslave.



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

Re: Review Request: More kio_sftp login related fixes

[Andreas Schneider]

> On April 21, 2012, 9:05 a.m., Andreas Schneider wrote:
> > Did you also test if keyboard-interactive still works correctly?
> 
> Dawit Alemayehu wrote:
> No, because I do not even know how to enable that functionality in my ssh 
> config and was lazy to search and find out. Just looking at the code though I 
> immediately see a problem where it sets the error message in the first dialog 
> box which will cause the retry dialog to be shown. I dunno if that was 
> intentional, but it is wrong. The user will not only see the message sent 
> from the ioslave, but also gets the question "Do you want to retry?".
> 
> BTW, I take back what I stated in the description of problem #1. It is 
> not my last patch that caused the bug. It is there prior to my patch as well 
> since I checked out and tested v4.8.0 to see if that was the case. Anyhow, I 
> can try to see if I can figure out how to enable keyboard interactive mode 
> and test that too. 
> 
> For the record I did not actually set out to fix these issues in 
> kio_sftp. It resulted from my work on fixing problems in kpasswdserver. I 
> needed someway to test those changes and the ssh server happens to be 
> something that is already up and running on my system. Lucky kio_sftp. ;)
> 
> Andreas Schneider wrote:
> Normally password authentication is turned off in the ssh server (default 
> for openssh) and keyboard interactive is used. There are some flaws in 
> password authentication and keyboard-interactive is a much more flexible way. 
> So if you have current Linux distribution then password authentication is 
> turned of and you have keyboard-interactive authentication connecting to 
> localhost.
> 
> Thanks for all the fixes. I don't have time for libssh and kio_sftp 
> lately. There are other projects I need to drive forward right now :)
> 
> Dawit Alemayehu wrote:
> Well I finally had the time to figure out how to activate keyboard 
> interactive and completely cleaned up the sftp login code to make it more 
> readable. I removed the usage of the go to statement to avoid iterating 
> through all the authentication methods just to retry password authentication. 
> However, for the life of me I cannot figure out how the 
> authenticateKeyboardInteractive is supposed to work. For me it does not work 
> at all because it does not prompt me for the password. I read documentation 
> you provided at 
> http://api.libssh.org/stable/libssh_tutor_authentication.html. 
> 
> What I gathered from reading the documentation is that, in keyboard 
> interactive mode, the server can send a challenge for which the user is 
> supposed to provide an answer. The server indicates that it is sending such 
> challenge prompt by setting the echo parameter to 1. Is that correct ? If it 
> is, how that is then handled is rather befuddling to me. For example, the 
> errorMsg parameter of the openPassword function is always set to the same 
> text. That will cause the retry dialog to be shown with the "Do you want to 
> retry?" question mark. Was that intentional ? What is being achieved by that. 
> I would have tested it myself I had known what option to set in sshd_config 
> to make the server send such challenge. I am sure if 
> 
> The scenario I was able to test on my system is where the echo parameter 
> is set to 0 and the prompt is set to "Password". In that case for some 
> reason, the user is never prompted to enter the password. Instead the value 
> of mPassword is assigned to it. Was that because the other password dialog 
> (one used for authentication) was used to prompt for username and password 
> already ? Anyhow, I have attached the latest incarnation which cleans up all 
> the previous authentication related changes I made. It is much cleaner and 
> easier to understand the flow of the authentication code now.
> 
> Andreas Schneider wrote:
> Keyboard interactive can ask for the username and 10 questions about Star 
> Wars before it will ask you for the password. You don't know how the password 
> question will look but in most of the cases it is "Password:". So there 
> should be a case handling username + "Password:" question.
> 
> You can also simply extend keyboard interactive. Ask for password + a one 
> time password from a token. This way it is pretty flexible. The 'echo' flag 
> is just for your if you should echo to the console what the server asks or 
> not. If echo is set we should use a Password field instead of a normal input 
> field.
> 
> I don't know what you mean with the errorMsg. I don't see something in 
> the authenticateKeyboardInteractive() function.
> 
> Dawit Alemayehu wrote:
> Right. I gathered keyboard interactive can ask multiple questions before 
> it asks for the password. What I am baffled about is how it is currently 
> being handled in authenticateKeyboardInteractive. Perhaps it would have been 
> clearer if I simply stated the problems that I have after

Re: kio and frameworks 5

[Ben Martin]

I thought I would hihack a reply to the windows support response to this
message.

For me that hasn't ever really been a priority so there isn't much
support for it right now. The main issue would be the Linux file
monitoring used by the file:// module. Beyond that there are some POSIX
calls which might not be available on windows, for example
posix_fadvise() or copying files through madvise()ed mmaped locations.

I don't see any of these as show stoppers though. Just some chunks of
code which will need to be ifdefed or more cleanly replaced with
alternate modules and some posix glue APIs.

On Fri, 2012-05-11 at 21:33 +0100, Casper Clemence wrote:
> I'm want to start a discussion, put an idea out there. I am also being
> pushy, on someone else's behalf.
> 
> 
> Although it may be a difficult discussion I think it would be a great
> shame to miss the opportunity to have it. I'm not trying to tell
> anyone to "do it this way".
> 
> 
> Please excuse me for saying "we" when I have not contributed to KDE as
> a developer, I tied myself in knots trying to write in the third
> person and gave up.
> 
> 
> Preamble over.
> 
> 
> The discussions is this "what part should libferris take in the
> refresh of KIO in KDE Frameworks 5?"
> 
> 
> Ben Martin really should be involved in any discussion of a redesign
> at the very least. He clearly has put a lot of work and thought into
> virtual filesystems and has created something quite unique.
> 
> 
> Libferris is an awesome piece of technology. It provides not just the
> traditional features of a VFS but a uniform method of access for
> applications and users to a large and expanding range of things. It
> has been demonstrated to work on maemo and as a Plasma DataEngine and
> has a web service interface. The rate at which Ben is able to turn out
> new capabilities for libferris also suggests it is well written and
> easy to develop.
> 
> 
> A uniform method of access for applications makes developing cool new
> stuff easier. A uniform method of access for users leads means a
> powerful tool to do what you want with your data, browsing a database
> in your file browser and dragging and dropping data around.
> 
> 
> So there are three points I want to suggest:
> (1) Speak to Ben about the possible developments of kio
> (2) learn from libferris
> (3) consider adopting libferris wholesale
> 
> 
> Possibly the biggest pain point with adopting libferris wholesale is
> that libferris indexes and KDE already has an indexer in strigi.
> 
> 
> But before the idea of adopting it wholesale into kdelibs is thrown
> out we should ask whether the difficulty of solving any issues we have
> with it really are greater than the difficulty of writing - and the
> advantage of those features libferris has which would never get
> written into kio.
> 
> 
> Libferris can already talk to soprano and Nepomuk, perhaps it should
> be considared whether allowing libferris to take over from strigi
> could actually be a good thing. Integration of the indexer into the
> VFS seems quite smart especially when the VFS knows how to read the
> structure of documents as well as index the text and metadata. I don't
> think that it is an easy question, whether or not it is worth it can
> only be answered by looking into it in technical detail, even trying
> it out.
> 
> 
> ---
> I hope this was a useful conversation to start and I am not just being
> an ignorant user butting in on the development mailing list.
> 
> 
> Regards to you all
> Casper
> 
> 

Re: kio and frameworks 5

[Casper Clemence]

On 13 May 2012 11:58, David Faure  wrote:
>
> On Sunday 13 May 2012 11:32:46 Casper Clemence wrote:
> > * it mounts lots more than an ordinary VFS - including XML documents (so
> > the tree of the document can be browsed), databases, X (so that window
> > position and size for example can be read and modified as if they were
> > data
> > in the filesystem), web browser bookmarks...
> > .. all of which leads to the "uniform method of access" I mentioned
> > where
> > all sorts of document data, document structure and metadata becomes
> > available in a a uniform way.
>
> All this sounds synchronous (the data is always available right away).
> So it probably makes sense as a kioslave (so that all applications can
> access
> all of the above via KIO API), not as a replacement for KIO (which has to
> provide an asynchronous way of accessing network protocols).
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
>

libferris handles asynchronous IO including network protocols.

I don't want this to turn into me arguing that libferris
_should_defineately_replace_kio_ I really don't know enough about
either to do that.

A kio slave for libferris could be created.

I am wrong but I think that the interesting access and indexing that
libferris provides for metadata would serve KDE better if it were
integrated at the level of KIO rather than as a kio-slave.

I really urge any of you to have a quick look though some of the
feature descriptions and papers on the libferris site
http://www.libferris.com/ and some of the demos on Ben's blog
http://monkeyiq.blogspot.co.uk/ to get an idea of the fun things it
makes possible.

I would like to give a deeper answer but laptop battery is about to die

Re: kio and frameworks 5

[Casper Clemence]

In short it is a virtual file system. However it takes the concept further
in several respects (for a fuller answer read the "about" page):

* it mounts lots more than an ordinary VFS - including XML documents (so
the tree of the document can be browsed), databases, X (so that window
position and size for example can be read and modified as if they were data
in the filesystem), web browser bookmarks...
* it extracts useful metadata from all of these things and treats it in a
consistent way, it also allows the user to add meta-data.
* an interesting feature it has is "agents" who will intelligently tag
items (files etc) giving a certain confidence that they are such a thing,
the user can then accept or reject these tags. I can imagine this
interacting very usefully with the whole "activities" thing, where
intelligent suggestions as to what should be a part of your activity could
make the whole experience much more useful.
* ... much more (I mentioned before it works on maemo, can talk to Nepomuk,
has a REST interface)

.. all of which leads to the "uniform method of access" I mentioned where
all sorts of document data, document structure and metadata becomes
available in a a uniform way.

As to the previous question about MS Windows support, I am having a look at
what would be required to compile on that platform.

Regards,
C

On 13 May 2012 10:53, David Faure  wrote:

> On Friday 11 May 2012 21:33:35 Casper Clemence wrote:
> > Libferris is an awesome piece of technology. It provides not just the
> > traditional features of a VFS but a uniform method of access for
> > applications and users to a large and expanding range of things
>
> What does it do exactly, and how?
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
>
>

Re: Review Request: Plasma Components: TextField and TextArea: Show placeholders even if item has the focus

[Laszlo Papp]

> On May 9, 2012, 6:30 p.m., Mark Gaiser wrote:
> > Ehh optional perhaps?
> > I've seen forms behave like this before and back then when i first saw it i 
> > tried to delete the text.. Which obviously didn't happen. The text just 
> > disappears as soon as i start typing. I kinda dislike that behavior. I 
> > mean, there is a big fat blue focus border that has the purpose of telling 
> > the user that the one with the blue border (style dependent) is the one 
> > that currently has focus. The blinking cursor is yet another indication 
> > that the field has focus. I think that is enough.
> > 
> > Perhaps optional, but please not by default. This is just my opinion and i 
> > don't maintain plasma components (nor anything in KDE for that matter). 
> > You'd have to wait for a reply from some of the plasma component 
> > maintainers to get a final word on this.
> 
> Sebastian Kügler wrote:
> This just fixes a race condition, I don't quite understand your 
> reservation, Mark?
> 
> David Edmundson wrote:
> No it doesn't. Currently if you give an item focus you hide the 
> placeholder text. In this patch it only hides placeholder text after you 
> start typing.
> 
> David Edmundson wrote:
>  ^ That reply was at Sebastian where he says it's a fix, where it's 
> actually a large visual change. (reviewboard doesn't really show that very 
> well)
> 
> Sebastian Kügler wrote:
> Funny, because I ran into this exact behaviour last night, and to make it 
> work well, I had to resort to using a Timer which calls forceActiveFocus() on 
> the TextArea, not quite intuitive either.
> 
> Does anyone have a suggestion which satisfies both usecase without hacks?
> 
> Sebastian Gottfried wrote:
> Using a timer to give a text field the focus sounds really strange in my 
> ears.
> 
> We could obviously extend the API of the text fields with a boolean 
> property "showPlaceholderWhileFocused" and give the responsibility to decide 
> on the wanted behaviour to the application developer. But at least me would 
> prefer a consistent behaviour for all text fields.
> 
> Mark Gaiser wrote:
> The behavior is consistent right now. The defacto "standard" on the 
> internet right now for forms seems to be to have a placeholder text and 
> remove the placeholder as soon as the field gets focus. However, lately there 
> have been more sites that do keep the placeholder even while focused and only 
> moves away if you start typing. Like for example the twitter login page 
> (though that does make the placeholder text a bit more transparent when you 
> have the focus).
> 
> I think both options should be provided, but the default should be to 
> remove the placeholder as soon as it gets focus.
> 
> Yet again just my opinion.
> 
> Mathias Kraus wrote:
> How about the following:
> - pre-focused text field shows the placeholder
> - if the user press any key (e.g. Esc, arrow keys, backspace) or starts 
> typing, the placeholder disappears and does't appear again, even if the text 
> field is empty
> - it the user clicks into a text field, the placeholder also disappears 
> immediatelly
> 
> Laszlo Papp wrote:
> I do not have too strong opinions about either way; just some additional 
> data fwiw:
> 
> 1) QLineEdit - clear for focus
> http://qt-project.org/doc/qt-4.8/qlineedit.html#placeholderText-prop
> 
> 2) KLineEdit - most likely the same since there is no such an addition 
> for KLineEdit, but inherits this from QLineEdit
> 
> 3) Harmattan components: clear for typing
> 
> 4) Symbian components: 
> http://doc.qt.nokia.com/qt-components-symbian/qml-textfield.html#placeholderText-prop
> 
> 5) Interesting that the following html practice shares the opinions as 
> well:
> 
> http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_input_placeholder
> 
> On Linux with firefox, rekonq and so forth, it produces the behavior that 
> the placeholder is gone for focus. On the contrary, the form keeps the 
> placeholder until typing on Windows.
> 
> Thomas Lübking wrote:
> The reason for the "clear on focus" behavior is to not confuse the user 
> about the content as soon as the entry is focused ("about to be used")
> 
> The "legacy" way in this regard (pre-focused & hinting lineedits) was to 
> also prefill the lineedit with the hint and pre-select the entire text 
> (especially if you really just want some input here or assume a "Cancel" 
> otherwise)
> Maybe -and if an empty string is no valid entry- one could merge those - 
> start with the prefilled selection, remove it and show the hint when the 
> focus is lost w/o typing.
> No idea whether this can be done in a purely declarative way, though.
> 
> As for changing the focus with a timer, ie. while the event chain is 
> running - a hack that would QTimer::singleShot(3, this, SLOT) to cross some 
> queued init code is one thing (not dete

Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror

[Thomas Lübking]

you probably wanted to point out that dawit ignored the perception of
a typical user when introducing this checkbox, but it actually could
be read as a disqualifying assumption about the condition of his mind.

latter would indeed be ad hominem and not ad res, but ultimatily what
we have here is just called "friction" (many ppl. from different
cultures talking in a foreign language)

so i suggest we just leave it to this and drop that discussion, for
the touched webkit/khtml item is rather prone to drag it down a dirty
path by less professional followers of k-c-d.

Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror

[Albert Astals Cid]

El Diumenge, 13 de maig de 2012, a les 14:27:37, Sebastian Kügler va escriure:
> On Sunday, May 13, 2012 12:20:00 Albert Astals Cid wrote:
> > You probably don't have any bit of user mentallity left in your head,
> 
> I think everybody is served better by discussions that do not engage in
> personal attacks.

This was in no way a personal attack. You'll realize when I do a personal 
attack.

> Let us please try to keep it respectful and technical

I have been respectful and technical.

> and avoid ad-hominem attacks. 

No ad-hominem attack happened, an ad-hominem attack would be saying "Don't 
listen to him, he is a communist", since being communist or not does not have 
any effect on his technical hability, but might put people against him.

> Respect is an important basis for making progress in a
> collaborative way.

Sure it is.

Cheers,
  Albert

> 
> Thanks,

Re: Review Request: kjs: Fix Errorprototype inheritance

[Maks Orlovich]

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

Ship it!


Ship It!

- Maks Orlovich


On May 10, 2012, 7:01 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104908/
> ---
> 
> (Updated May 10, 2012, 7:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Fix Errorprototype inheritance, it must inherit from ErrorInstance to 
> get the correct classInfo
> 
> 
> Without the patch
> 
> Error.prototype.toString=Object.prototype.toString;
> print(Error.prototype.toString());
> 
> will tell us that Error is an Object, not an Error
> 
> before:
> [object Object]
> 
> after:
> [object Error]
> 
> 
> Diffs
> -
> 
>   kjs/error_object.h c3cd64d 
>   kjs/error_object.cpp 1f176d7 
> 
> Diff: http://git.reviewboard.kde.org/r/104908/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Introduce & use leftFirst parameter in relation check, according to Ecmascript 5.1r6.

[Maks Orlovich]

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


Any performance effect?

- Maks Orlovich


On May 10, 2012, 7:01 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104906/
> ---
> 
> (Updated May 10, 2012, 7:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Introduce & use leftFirst parameter in relation check, according to 
> Ecmascript 5.1r6.
> 
> This fixes the access order for Greater-than and Less-than-or-equal Operator
> 
> 
> NOTE: please ignore patch r1, it was the wrong patch, luckily normal View 
> Diff always points to the latest version :)
> 
> 
> Diffs
> -
> 
>   kjs/bytecode/codes.def bcd2e3a 
>   kjs/operations.h f8a28c8 
>   kjs/operations.cpp d4c0066 
> 
> Diff: http://git.reviewboard.kde.org/r/104906/diff/
> 
> 
> Testing
> ---
> 
> ecma 11.8.2 tests
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Update Error.prototype.toString to ECMA Edition 5.1r6 format

[Maks Orlovich]

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

Ship it!


Ship It!

- Maks Orlovich


On May 10, 2012, 7:01 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104907/
> ---
> 
> (Updated May 10, 2012, 7:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Update Error.prototype.toString to ECMA Edition 5.1r6 format
> 
> only slightly different from existing format, but nicer in case name or 
> message is empty
> 
> 
> Diffs
> -
> 
>   kjs/error_object.cpp 1f176d7 
> 
> Diff: http://git.reviewboard.kde.org/r/104907/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Implement standard String.trim, also non-standard trimLeft & trimRight

[Maks Orlovich]

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

Ship it!


.. One of these days I'll manage to use reviewboard properly.


- Maks Orlovich


On May 4, 2012, 5:40 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104857/
> ---
> 
> (Updated May 4, 2012, 5:40 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Implement standard String.trim, also non-standard trimLeft & trimRight
> 
> As trimLeft&trimRight are very similar and easy to implement in trim, and all 
> modern browser support it as well, I also added it.
> 
> depends on https://git.reviewboard.kde.org/r/104855/
> 
> 
> Diffs
> -
> 
>   kjs/string_object.h e890d52 
>   kjs/string_object.cpp 170e2f7 
> 
> Diff: http://git.reviewboard.kde.org/r/104857/diff/
> 
> 
> Testing
> ---
> 
> ecma Strimg.trim tests
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Implement standard String.trim, also non-standard trimLeft & trimRight

[Maks Orlovich]

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



kjs/string_object.cpp


Could you use a const pointer here to make this look less scary?



- Maks Orlovich


On May 4, 2012, 5:40 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104857/
> ---
> 
> (Updated May 4, 2012, 5:40 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Implement standard String.trim, also non-standard trimLeft & trimRight
> 
> As trimLeft&trimRight are very similar and easy to implement in trim, and all 
> modern browser support it as well, I also added it.
> 
> depends on https://git.reviewboard.kde.org/r/104855/
> 
> 
> Diffs
> -
> 
>   kjs/string_object.h e890d52 
>   kjs/string_object.cpp 170e2f7 
> 
> Diff: http://git.reviewboard.kde.org/r/104857/diff/
> 
> 
> Testing
> ---
> 
> ecma Strimg.trim tests
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Fix parseFloat not cutting-off leading unicode spaces

[Maks Orlovich]

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


I think this is the wrong place to fix this, actually; I think you want to 
change it in ustring.cpp so it affects
the implicit conversions as well. Testcase:

"\u180e6"*7 

(See also 9.3.1)


- Maks Orlovich


On May 4, 2012, 5:40 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104858/
> ---
> 
> (Updated May 4, 2012, 5:40 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Fix parseFloat not cutting-off leading unicode spaces
> 
> parseInt cuts away the leading spaces, like it should, but we don't to it for 
> parseFloat, like we should.
> UString::toDouble does remove leading spaces, but only ascii spaces, no 
> unicodespaces.
> 
> ECMA 15.1.2.3 Step 2 confirms that leading spaces should be cut
> 
> depends on https://git.reviewboard.kde.org/r/104855/
> 
> 
> Diffs
> -
> 
>   kjs/function.cpp 5f39ae6 
> 
> Diff: http://git.reviewboard.kde.org/r/104858/diff/
> 
> 
> Testing
> ---
> 
> Fixes a couple of ecma parseFloat tests
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Unify/de-duplicate Space checking

[Maks Orlovich]

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

Ship it!


- Maks Orlovich


On May 4, 2012, 5:40 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104855/
> ---
> 
> (Updated May 4, 2012, 5:40 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Unify/de-duplicate Space checking
> 
> function.cpp isStrWhiteSpace was missing "0xFEFF:  // ZERO WIDTH NO-BREAK 
> SPACE"
> 
> 
> Diffs
> -
> 
>   kjs/commonunicode.h PRE-CREATION 
>   kjs/function.cpp 5f39ae6 
>   kjs/lexer.cpp e89de5f 
> 
> Diff: http://git.reviewboard.kde.org/r/104855/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Unify/de-duplicate Space checking

[Maks Orlovich]

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



kjs/commonunicode.h


This needs a bit of a comment tweak --- it's not in Zs but rather Cf, but 
ES 5th edition treats it specially.
(And differently from the rule in 3rd edition, which no-one implemented).



- Maks Orlovich


On May 4, 2012, 5:40 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104855/
> ---
> 
> (Updated May 4, 2012, 5:40 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Unify/de-duplicate Space checking
> 
> function.cpp isStrWhiteSpace was missing "0xFEFF:  // ZERO WIDTH NO-BREAK 
> SPACE"
> 
> 
> Diffs
> -
> 
>   kjs/commonunicode.h PRE-CREATION 
>   kjs/function.cpp 5f39ae6 
>   kjs/lexer.cpp e89de5f 
> 
> Diff: http://git.reviewboard.kde.org/r/104855/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror

[Sebastian Kügler]

On Sunday, May 13, 2012 12:20:00 Albert Astals Cid wrote:
> You probably don't have any bit of user mentallity left in your head,

I think everybody is served better by discussions that do not engage in 
personal attacks. Let us please try to keep it respectful and technical, and 
avoid ad-hominem attacks. That keeps k-c-d a more friendly place to everyone. 
Respect is an important basis for making progress in a collaborative way.

Thanks,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror

[Albert Astals Cid]

> On April 26, 2012, 5:09 p.m., Albert Astals Cid wrote:
> > If i understand you correctly you are suggesting to create a bug (option 
> > that does nothing)?
> > 
> > Doesn't make much sense.
> 
> Dawit Alemayehu wrote:
> Huh ? I do not follow. By "option that does nothing" you mean this change 
> by itself does nothing that is correct. But that is true of every option in 
> that dialog as well. Moreover, it is a well known fact that you cannot post a 
> patch for different components in reviewboard. Anyhow, the option will most 
> definitely be used by kwebkitpart. Whether or not some body implements 
> support for it in khtml is a question I cannot answer. That is what I meant.
> 
> David Faure wrote:
> Do you have the kwebkitpart patch ready?
> I suppose it'll be easy to "apply" to khtml as well.
> 
> Albert Astals Cid wrote:
> You are suggesting to add an option that does nothing in our default html 
> rendering engine. That is adding a bug. The fact that you know it and don't 
> care about it makes me sad.
> 
> Dawit Alemayehu wrote:
> @David: Yes I have a patch for kwebkitpart, but unlike in khtml adding 
> support for this in kwebkitpart required a very small change in one place in 
> addition to adding code to read the config option itself in 
> webkitettings.{h|cpp}. That does not seem to be the case in khtml. It is a 
> little bit more invovled.
> 
> @Albert: Really ?? So how exactly is another browser engine supposed to 
> provide configuration option to the user if it is supposed to be embedded 
> into Konqueror ?  Why would a developer working on a separate browsing engine 
> be forced to implement any functionality into khtml ? Would that requirement 
> apply the other way around ? The last I checked, this is a konqueror setting. 
> Whether a specific browser engine supports it or not is up to that browser 
> engine.Just for the record I almost always go out of my way to implement 
> things in khtml ; especially when I factor out features that are common to 
> both engines. In this case, I neither have the time nor a complete grasp of 
> how the KWallet integration works in khtml. As I stated above the change is 
> not in a single isolated location like it is in kwebkitpart. Feel free to do 
> a grep in khtml and see for yourself. I can always add the set/get functions 
> to access the option in KHTMLSettings, but what use would that be if it is 
> not implemented. 
> 
> Anyhow, I digress. If there are objections, I will simply move this 
> feature into the webkit config module I will have to create down the road.

"So how exactly is another browser engine supposed to provide configuration 
option to the user if it is supposed to be embedded into Konqueror ?"
Having it's own engine-only kcm for it's engine-specific options?

"Why would a developer working on a separate browsing engine be forced to 
implement any functionality into khtml ?"
When did i say that?

"Would that requirement apply the other way around ?"
If you want to use the "general" apply to all engines options page, of course.

You probably don't have any bit of user mentallity left in your head, because 
it's pretty obvious that adding a configuration option to "web rendering 
configuration" that won't work with our default rendering engine it's bad 
usability.

But hey, since David promised to implement this for khtml, go ahead, don't let 
me block progress.


- Albert


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


On April 26, 2012, 3:48 a.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104631/
> ---
> 
> (Updated April 26, 2012, 3:48 a.m.)
> 
> 
> Review request for KDE Base Apps, kdelibs and David Faure.
> 
> 
> Description
> ---
> 
> A patch to make that provides an option to disable the "offer to save website 
> passwords". Note that for this patch to take effect this option will have to 
> be used at at the browser engine level. Those patches are separate to this 
> one. This is just the GUI configuration.
> 
> 
> Diffs
> -
> 
>   konqueror/settings/konqhtml/htmlopts.h 69f36d8 
>   konqueror/settings/konqhtml/htmlopts.cpp e5d6deb 
> 
> Diff: http://git.reviewboard.kde.org/r/104631/diff/
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> Option for disabling KWallet integration
>   http://git.reviewboard.kde.org/r/104631/s/544/
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Re: kio and frameworks 5

[David Faure]

On Sunday 13 May 2012 11:32:46 Casper Clemence wrote:
> * it mounts lots more than an ordinary VFS - including XML documents (so
> the tree of the document can be browsed), databases, X (so that window
> position and size for example can be read and modified as if they were data
> in the filesystem), web browser bookmarks...
> .. all of which leads to the "uniform method of access" I mentioned where
> all sorts of document data, document structure and metadata becomes
> available in a a uniform way.

All this sounds synchronous (the data is always available right away).
So it probably makes sense as a kioslave (so that all applications can access 
all of the above via KIO API), not as a replacement for KIO (which has to 
provide an asynchronous way of accessing network protocols).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

Re: kio and frameworks 5

[Kevin Krammer]

On Sunday, 2012-05-13, David Faure wrote:
> On Friday 11 May 2012 21:33:35 Casper Clemence wrote:
> > Libferris is an awesome piece of technology. It provides not just the
> > traditional features of a VFS but a uniform method of access for
> > applications and users to a large and expanding range of things
> 
> What does it do exactly, and how?

There have been a couple of blog postings on planetkde showing what it can do 
[1], but I have no idea how it works.

Cheers,
Kevin

[1] http://monkeyiq.blogspot.com/search/label/libferris
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


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

Re: kio and frameworks 5

[Thiago Macieira]

On domingo, 13 de maio de 2012 11.53.13, David Faure wrote:
> On Friday 11 May 2012 21:33:35 Casper Clemence wrote:
> > Libferris is an awesome piece of technology. It provides not just the
> > traditional features of a VFS but a uniform method of access for
> > applications and users to a large and expanding range of things
> 
> What does it do exactly, and how?

I'm more interested in what it does better than KIO. Why should we consider 
switching?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


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

Re: kio and frameworks 5

[David Faure]

On Friday 11 May 2012 21:33:35 Casper Clemence wrote:
> Libferris is an awesome piece of technology. It provides not just the
> traditional features of a VFS but a uniform method of access for
> applications and users to a large and expanding range of things

What does it do exactly, and how?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

Re: Review Request: More kio_sftp login related fixes

[Andreas Schneider]

> On April 21, 2012, 9:05 a.m., Andreas Schneider wrote:
> > Did you also test if keyboard-interactive still works correctly?
> 
> Dawit Alemayehu wrote:
> No, because I do not even know how to enable that functionality in my ssh 
> config and was lazy to search and find out. Just looking at the code though I 
> immediately see a problem where it sets the error message in the first dialog 
> box which will cause the retry dialog to be shown. I dunno if that was 
> intentional, but it is wrong. The user will not only see the message sent 
> from the ioslave, but also gets the question "Do you want to retry?".
> 
> BTW, I take back what I stated in the description of problem #1. It is 
> not my last patch that caused the bug. It is there prior to my patch as well 
> since I checked out and tested v4.8.0 to see if that was the case. Anyhow, I 
> can try to see if I can figure out how to enable keyboard interactive mode 
> and test that too. 
> 
> For the record I did not actually set out to fix these issues in 
> kio_sftp. It resulted from my work on fixing problems in kpasswdserver. I 
> needed someway to test those changes and the ssh server happens to be 
> something that is already up and running on my system. Lucky kio_sftp. ;)
> 
> Andreas Schneider wrote:
> Normally password authentication is turned off in the ssh server (default 
> for openssh) and keyboard interactive is used. There are some flaws in 
> password authentication and keyboard-interactive is a much more flexible way. 
> So if you have current Linux distribution then password authentication is 
> turned of and you have keyboard-interactive authentication connecting to 
> localhost.
> 
> Thanks for all the fixes. I don't have time for libssh and kio_sftp 
> lately. There are other projects I need to drive forward right now :)
> 
> Dawit Alemayehu wrote:
> Well I finally had the time to figure out how to activate keyboard 
> interactive and completely cleaned up the sftp login code to make it more 
> readable. I removed the usage of the go to statement to avoid iterating 
> through all the authentication methods just to retry password authentication. 
> However, for the life of me I cannot figure out how the 
> authenticateKeyboardInteractive is supposed to work. For me it does not work 
> at all because it does not prompt me for the password. I read documentation 
> you provided at 
> http://api.libssh.org/stable/libssh_tutor_authentication.html. 
> 
> What I gathered from reading the documentation is that, in keyboard 
> interactive mode, the server can send a challenge for which the user is 
> supposed to provide an answer. The server indicates that it is sending such 
> challenge prompt by setting the echo parameter to 1. Is that correct ? If it 
> is, how that is then handled is rather befuddling to me. For example, the 
> errorMsg parameter of the openPassword function is always set to the same 
> text. That will cause the retry dialog to be shown with the "Do you want to 
> retry?" question mark. Was that intentional ? What is being achieved by that. 
> I would have tested it myself I had known what option to set in sshd_config 
> to make the server send such challenge. I am sure if 
> 
> The scenario I was able to test on my system is where the echo parameter 
> is set to 0 and the prompt is set to "Password". In that case for some 
> reason, the user is never prompted to enter the password. Instead the value 
> of mPassword is assigned to it. Was that because the other password dialog 
> (one used for authentication) was used to prompt for username and password 
> already ? Anyhow, I have attached the latest incarnation which cleans up all 
> the previous authentication related changes I made. It is much cleaner and 
> easier to understand the flow of the authentication code now.

Keyboard interactive can ask for the username and 10 questions about Star Wars 
before it will ask you for the password. You don't know how the password 
question will look but in most of the cases it is "Password:". So there should 
be a case handling username + "Password:" question.

You can also simply extend keyboard interactive. Ask for password + a one time 
password from a token. This way it is pretty flexible. The 'echo' flag is just 
for your if you should echo to the console what the server asks or not. If echo 
is set we should use a Password field instead of a normal input field.

I don't know what you mean with the errorMsg. I don't see something in the 
authenticateKeyboardInteractive() function.


- Andreas


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


On April 26, 2012, 3:42 a.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically gener