In case my last comment was mistakable, I fixed this:
- Create a document with just one long line that wraps over two printed pages. I this case, I am not able to print only the selected text properly.
In case my last comment was mistakable, I fixed this:
- Create a document with just one long line that wraps over two printed pages. I this case, I am not able to print only the selected text properly.
Here is the fix for 1.
Yes, I am working on it. Now, I have a solution for 1, but 2 is more difficult to fix. Probably next week.
Yes, I do, but this will be my first push and I don't want to break something. So all I have to do is
arc land
in my feature branch to merge these two commits and push (push remote is git://git.kde.org/dolphin.git). Correct?
In D21563#584484, @hoffmannrobert wrote:In D21563#584218, @dhaumann wrote:@hoffmannrobert: Are you maybe also interested in looking into https://bugs.kde.org/show_bug.cgi?id=415570 ? It's again about printing, this time about the very last line that seems to be wrong...
Yes, I can reproduce the bug. I'll look into it in about two weeks.
Added const, renamed variables.
In D21563#584220, @dhaumann wrote:@hoffmannrobert: by the way, looking at your phabricator activity, you should get a KDE contributor account, if you don't have one already.
In D21563#584218, @dhaumann wrote:@hoffmannrobert: Are you maybe also interested in looking into https://bugs.kde.org/show_bug.cgi?id=415570 ? It's again about printing, this time about the very last line that seems to be wrong...
In D25732#573058, @dfaure wrote:This should go into KDirWatch itself then, to avoid the risk of other callers falling into that trap.
Thanks, I moved the reload() and added a signal readyForDirListerStart() to DocumentFactory, which is emitted when the document is loaded or failed. In ContextManager::setUrlToSelect() this signal is connected to the dirlister start.
The connects at ContextManager::setUrlToSelect() only work with the if (UrlUtils::urlIsFastLocalFile()) determination.
You are right, I changed it to use the signals from the document loaded (or not).
In D21563#487947, @cullmann wrote:I tried to reproduce the issue with and without this fix but I somehow fail.
Has somebody else more luck?
I tested the new code:
Tests 1-5 of the test plan behave like previously "without patch", in tests 6 and 7 the integrated laptop screen isn't reacitivated after opening.
Rebase and adapt to new upstream code
Can you please push it for me, I don't have commit access. Thanks.
It fixes this bug: https://bugs.kde.org/show_bug.cgi?id=348598
In D21563#473734, @ngraham wrote:
I added some more fixes:
In D21082#463848, @romangg wrote:This is the real issue. Why are the screen positions scrambled around although there should be a config from before shutdown/suspend (not the lidOpened one), that has the current positions stored. Apparently this one has the wrong positions saved as well. You could check this in your config files.
My goal is to make the screen configurations work reliably with notebooks, not to support a new use case. The use case is: work with a notebook docked and undocked, with and without external screen(s), lid open or closed.
In D20197#445098, @dfaure wrote:Ah! So "DirOrFile" means the user can see and choose both directories and files? Maybe call this ModeWasDirAndFile. I kept reading this was "mode was dirs or mode was files" (which made me say "what else is there?"), while now I think I understand it means "mode was (both dir+files)", right?
Thanks, I've learned that QFileDialog only creates a well behaving directory chooser, if the QFileDialog::ShowDirsOnly option is set to true _after_ having set the fileMode to QFileDialog::Directory. If you do it the other way around, it doesn't add directories to the selection.
Is there a different decided directory chooser than QFileDialog?
You need to double click the directory, so you enter the directory, then click Open.
In D20197#442358, @ngraham wrote:This doesn't work. Try creating a symlink to a directory. In the file picker dialog, the Open button doesn't work.
See https://bugs.kde.org/show_bug.cgi?id=357171 for more context.
Yes, please, and https://phabricator.kde.org/D19784 too.
JobTest also fails, but this fails in master, too. Something with FileCopyJob.
In D19784#437715, @dfaure wrote:
...
Indeed this doesn't need the stat() done by KFileItem's init(). This means the right solution is indeed for KFileItem to do that stat() on demand, and this code doesn't need any changes.
In D19784#434564, @hoffmannrobert wrote:In D19784#431683, @ngraham wrote:Nice, kinda sounds like this fixes https://bugs.kde.org/show_bug.cgi?id=373352. Can you confirm?
No, unfortunately it doesn't fix this. If the network isn't available, the file dialog waits for KCoreDirLister ("Iterating over dirs").
No, thanks, I have a sponsor, but I don't have commit access. Please push it for me.
In D19786#433580, @sitter wrote:setting server to keepalive=false? what is this? the 90's? :O
In D19784#431683, @ngraham wrote:Nice, kinda sounds like this fixes https://bugs.kde.org/show_bug.cgi?id=373352. Can you confirm?
No, I don't have commit access. Please push it for me, thanks.
Could you please land it for me, I don't have commit access. Thanks.
QDir not required, just add '/'
Thanks for reviewing. Can you please land it for me, I don't have commit access.
Fix crash if screen numbers are not consecutive.
Add ShellCorona::screenForId(int screenNum) for easy access to a panel's QScreen replacing wrong access via QGuiApplication::screens().at(screenNum).
Thank you. If these non-consecutive screen numbers are legitimate, then getting the QScreen via QGuiApplication::screens().at(screenNum) is wrong. I found a solution using ShellCorona::m_desktopViewforId.
In D10344#297751, @hoffmannrobert wrote:In Wayland there seems to be a problem with QScreen: creating a panel on the second screen crashes plasmashell in QScreen::size(), called by PanelView::panelConfig() (shell/panelview.cpp:130).
Sorry for the delay.
Regard focus window position only if manually creating panels.
Can somebody please land this patch for me? Thanks.
Addition to last comment: In the other case, booting with HDMI-2 and hotplugging HDMI-3 the problem with primary switching doesn't exist.