Don't change height accelerator

port -> Port

This is a change that would greatly benefit from an auto test, sadly we don't have to have any in lokalize.

Any new feature needs to be based on master which is where it will land.

I already disagreed that method is the correct solution, so no it's not "the same way"

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

I would like to discuss if we should enclose every placeholder used in KI18n with the two isolation characters

I'm not convinced "Incomplete" is the best name, but people will understand what it means quickly so i think this can go in.

You can't add new features to a stable branch

For message 3 this is my suggestion, what do you think?

Well, you're the de-facto mainitaner now, so i'll have to trust you, i'd say if noone complains in a week, just commit this. (with the two small things fixed if possible)

I'm with you that having a possibility to just compile kdnssd without any backend may be of value so i would either not commit this or improve the cmake so there's a way to say I_KNOW_WHAT_I_AM_DOING_KEEP_GOING

In D13219#273109, @safaalfulaij wrote:

https://bugs.kde.org/show_bug.cgi?id=388642

Just saying... :)

But 2018 is not a number, it's a year ;)

In D13114#269422, @chinmoyr wrote:

In D13114#269280, @aacid wrote:

Can you explain what's the use case for this?

Adobe reader allows user to view different signed revisions of a PDF. This patch intends to implement
that feature.

I thought we had agreed that using qvariantmaps for passing structures was a bad idea.
If i have to implement this for my AwesomeGenerator, how do i know what comes in revData?

My bad, I thought you were talking about returning a QVariantMap. I will correct it in next update.

Also the API is weird, you have

QString generateDocumentRevision( int revNum );

but which revNums are you going to use.

The revision number starts from 1 and goes till the total number of signature form fields. The idea here is to
include the total number of signature fields in generator's metadata

I'm not too thrilled about this to be honest, seems that this is something i18n should be doing by default, pinging @ilic to see what he would think about fixing/expanding ki18n to do "the right thing" by default

Are you planning in adding an auto test for this?

Do you know if there's a minimum version of libvncserver we should require so that it has that listen6Sock?

I think it was agreed this is an improvement, so i'm going to suggest we commit it.

make salt be on the stack
Also use better_write instead of write

It would defenitely be nicer using a template for this instead of the big define, but if you already tried it i don't really object much, i'm fine with this and will commit it (or you can) once you fix the remaining comments for the associated test

QTest::qWait( 100 ); is bad as you probably already guessed since it's "machine dependant".

I'm not very happy of the internalText method/storage in form, ideally, the text in core/form should always be the internal text, and if there's a formatted text that needs to be different that should only be as part of the widget itself. i.e. the FormLineEdit would do something like

Can you explain what's the use case for this?

have you tried this? because i have just tried it and it failed.

review comments

if there's other places using the backslash it's fine, no need to change :)

Are you sure about that? I remember a discussion i had long time ago with an usability person and i think he mentioned showing and hiding menu actions is usually not the best of the ideas because it confuses the user that things the action was there and when it isn't gets confused and thinks it's either somewhere else or that he misremembered, but if instead the action is disabled, usually the user thinks "ah, i need to move to a different state to enable this".

Are you sure you need the backslashes in add_definitions?

In D10974#267998, @ngraham wrote:

Stepping back a bit, I can identify the following two use cases:

• The document has its own margins that will make it fit within the printer's printable area without any scaling (e.g. a scientific paper or an eBook)
• The document will not fit within the printer's printable area without some scaling, either because it has no margins, or because its own margins are not big enough (e.g a flyer, magazine article, or advertisement)
  
  In the first case, you never need additional margins and always want the document printed with no scaling.
  
  In the second case, you always need to scale the document down to fit within the printable area, or else the edges will be clipped and you'll lose some of the content.
  
  If this analysis is complete, then we don't actually need a user-facing setting here at all; we should instead infer the correct setting for ourselves by seeing whether the document to be printed has its own margins that make it fit within the printer's printable area: if it does, print as-is; if it doesn't, then scale it until it fits.
  
  Am I on the right track, or is this an incomplete assessment?

In D10974#268014, @ngraham wrote:

If we use a checkbox, the string I would recommend is "Scale down to fit within printable area".

Looks good to me, if you want to make sure header and data alignment is the same maybe you can find a way to only have one switch instead of two (i.e. make data call headerData or viceversa or make them both call a new function) that way we enforce they're the same.

In D10974#267814, @michaelweghorn wrote:

@aacid: What's the right way to properly indicate that an important part of this
was actually done by you (add you in the copyright, mention in the commit message,...)?