[akregator] [Bug 337882] Search misbehaves when searching for titles containing single quotes

[Syam via KDE Bugzilla]

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

Syam  changed:

   What|Removed |Added

Version|4.12.5  |5.3.0

--- Comment #5 from Syam  ---
This bug exists with Akregator Version 5.3.0 (QtWebEngine).
I can't be sure about the behaviour when searching for "" for this version.
Titles with words with single quotes (Error'd, What's etc.) are not listed when
searching for that word.

It's very easy to reproduce. Just add the Daily WTF's feed and you can see for
yourself:
http://syndication.thedailywtf.com/TheDailyWtf

I have changed the version of the application to 5.3.0 for the report.

Fedora 24
KDE Frameworks 5.26.0
Qt 5.6.1 (built against 5.6.1)

-- 
You are receiving this mail because:
You are watching all bug changes.

[akregator] [Bug 175870] "feed" tab in message board vanishes sometimes

[Syam via KDE Bugzilla]

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

--- Comment #6 from Syam  ---
I can no longer recreate the bug with Akregator Version 5.3.0.

Fedora 24
KDE Frameworks 5.26.0
Qt 5.6.1 (built against 5.6.1)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 365825] Show desktop applet shortcut broken

[Syam via KDE Bugzilla]

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

Syam  changed:

   What|Removed |Added

 CC||get.so...@gmail.com

--- Comment #1 from Syam  ---
I can confirm this bug with Plasma 5.7.1 on Fedora 24.
Setting a keyboard shortcut for "Show Desktop" widget on the panel has no
effect.
However, if I go to System Settings > Shortcuts > Global Keyboard Shortcuts >
KWin and assign the shortcut to "Show Desktop" item, it works.

PS: I think it might be wrong to assign the bug against "kdeplasma-addons".
Somebody please change to the right product.

-- 
You are receiving this mail because:
You are watching all bug changes.

[akregator] [Bug 365276] New: Selecting/deleting an article does not work if 'search article' box has focus

[Syam via KDE Bugzilla]

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

Bug ID: 365276
   Summary: Selecting/deleting an article does not work if 'search
article' box has focus
   Product: akregator
   Version: unspecified
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kdepim-b...@kde.org
  Reporter: get.so...@gmail.com

Pressing Delete to delete an article while the 'search articles' text box has
focus does not work.

In general, I think there's some bigger problem with the way the article list
widget and the feeds list widget gets focus. The colour of the selected item in
both of these widgets is duller than the usual colour used for selected items.
If you doubleclick an item in the feeds list, the feed's name becomes editable
and then the item's background colour resembles that of a properly selected
item.

Reproducible: Always

Steps to Reproduce:
1. Select any feed to display the list of articles
2. Select any article to read it in the preview pane
3. Click on the 'search articles' text box
4. Select some other article
5. Notice that the focus is still on the search text box
6. Try to delete the selected article by pressing delete key
7. Nothing happens because the search text box still has the focus
8. The only way to get out is to click somewhere in the preview pane to shift
focus out of the search text box and then press Delete key



Akregator version: 5.2.2
Using:
KDE Frameworks 5.23.0
Qt 5.6.0 (built against 5.6.0)
The xcb windowing system

-- 
You are receiving this mail because:
You are watching all bug changes.

[kio] [Bug 352644] FTP shares exported by eShare app on Android are inaccessible from Dolphin with "Could not enter folder ." error message

[Syam via KDE Bugzilla]

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

--- Comment #5 from Syam  ---
I followed the instructions, and this is what comes up in ~/.xsession-errors:

kf5.kinit.klauncher: KLauncher: launching new slave
"/usr/lib64/qt5/plugins/kf5/kio/ftp.so" with protocol= "ftp" args= ("ftp",
"local:/run/user/1000/klauncherXM4514.1.slave-socket",
"local:/run/user/1000/dolphinBC5940.4.slave-socket")
kf5.kinit.klauncher: "/usr/lib64/qt5/plugins/kf5/kio/ftp.so" (pid 5961) up and
running.
error() called twice! Please fix the KIO slave.
Can't open for listing
error() called twice! Please fix the KIO slave.
kf5.kservice.sycoca: checking file timestamps
org.kde.kurifilter-shorturi: "ftp://192.168.0.3:6262;
org.kde.kurifilter-shorturi: path = ""  isLocalFullPath= false  exists= false 
url= QUrl("ftp://192.168.0.3:6262;)
org.kde.kurifilter-ikws: "ftp://192.168.0.3:6262; :
QUrl("ftp://192.168.0.3:6262;) , type = 0
kf5.kinit.klauncher: KLauncher: launching new slave
"/usr/lib64/qt5/plugins/kf5/kio/ftp.so" with protocol= "ftp" args= ("ftp",
"local:/run/user/1000/klauncherXM4514.1.slave-socket",
"local:/run/user/1000/dolphinHf5940.5.slave-socket")
kf5.kinit.klauncher: "/usr/lib64/qt5/plugins/kf5/kio/ftp.so" (pid 5966) up and
running.
error() called twice! Please fix the KIO slave.
Can't open for listing
error() called twice! Please fix the KIO slave.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kio] [Bug 352644] FTP shares exported by eShare app on Android are inaccessible from Dolphin with "Could not enter folder ." error message

[Syam via KDE Bugzilla]

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

--- Comment #3 from Syam  ---
Can somebody please take a look at this. If I need to do something to provide
more debug info,  do let me know.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 353195] Copy error for folders with mixed files & folders in Split View

[Syam via KDE Bugzilla]

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

--- Comment #17 from Syam  ---
(In reply to Kai Dombrowe from comment #16)

I can reproduce this at will on Fedora too.

Fedora 23, x86-64
Dolphin 15.12.1
KDE Frameworks 5.19.0
Qt 5.5.1 (built against 5.5.1)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 36065] dragging from a window should not raise it

[Syam via KDE Bugzilla]

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

--- Comment #49 from Syam  ---
(In reply to Syam from comment #48)
> (In reply to Martin Gräßlin from comment #47)
> > (In reply to Syam from comment #46)
> > 
> > Changing the action to be performed on release instead of press would be
> > rather weird. The window would not activate till you release. That's not
> > what a user (and applications) expects.
> 
> Is it really weird? I wonder how it is done on Windows? Does the background
> window raise at mouse-down itself or only on 'click', i.e. after mouse-up? I
> have to boot in to a Windows machine before confirming.

Just checked on Windows. You are right. The raise happens on mouse down itself,
unless its a drag.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 36065] dragging from a window should not raise it

[Syam via KDE Bugzilla]

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

--- Comment #48 from Syam  ---
(In reply to Martin Gräßlin from comment #47)
> (In reply to Syam from comment #46)
> > The problem is that this raise happens not on 'click' but on mouse-down
> > itself.
> 
> This is correct, the raise happens on press if that's the action you
> configured for what happens on click on inactive window. This is
> configurable. If you don't like the default of "Activate, Raise & Pass
> Click" change it to "Activate & Pass Click".

This has been suggested earlier. But it doesn't really work, because the
setting is really for mouse-down and not a 'click' (which is completed at
mouse-up). With "Activate and Pass click", the window won't be raised after one
click. The user needs to click on it again to raise it. And that is indeed
weird, I agree.

> 
> Changing the action to be performed on release instead of press would be
> rather weird. The window would not activate till you release. That's not
> what a user (and applications) expects.

Is it really weird? I wonder how it is done on Windows? Does the background
window raise at mouse-down itself or only on 'click', i.e. after mouse-up? I
have to boot in to a Windows machine before confirming.


> If we had any chance to know that
> the user intends to drag we could perform a different strategy.
I see from some earlier comments that the devs are stuck on this 'angle' to
solve the problem. But as mentioned in the original report, 'raising at
mouse-up and not immediately after mouse-down' would solve it without any need
to know if a drag is being done.

> 
> To me the issue is fixed. This bug report contains multiple suggestions on
> how it should behave. Several of them even contradicting.

Well, the original report mentions one problem and one solution. I understand
that it is difficult to implement this with current technology - as pointed out
in some earlier comment, on current Linux desktops & GUI libraries, everything
seems to happen at mouse-down and not on mouse-clicks.


> 
> Now as I'm the only one here who probably has tried this out, I ask you to
> first try it before starting discussions about the state of this bug report.

I am deeply sorry if my earlier comment offended you. I was afraid if it'd come
out like this. But I didn't mean any disrespect. I have very high regards for
devs, especially you :-)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 36065] dragging from a window should not raise it

[Syam via KDE Bugzilla]

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

--- Comment #46 from Syam  ---
(In reply to Martin Gräßlin from comment #45)
> > I'm not sure if that'd suffice. Consider the situation:
> 
> We considered this situation during our discussions and came to the
> conclusion that it's out of scope. The drag is performed from the active
> window, for the compositor it's impossible to know that the user clicked the
> window to perform a drag and that's also not how the Wayland protocol allows
> to start a drag (the click must(!) be passed to the window).

The problem is that this raise happens not on 'click' but on mouse-down itself.


> 
> There are multiple ways now to circumvent the problem:
Exactly! These are ways to 'circumvent' the problem. The problem exists and it
is disappointing to see that it'd still need to be worked around even though we
now have a perfect opportunity to fix this - Wayland new Qt etc etc.

> 
> We also think that the users are able to realize that they cannot drag from
> a maximized window and will change the geometry before. Just like users use
> split screen in Dolphin to better support drag'n'drop.

Hmm.. Users are not just 'able' to realise. They are forced to. And all these
workaround statements can be equally applied to removing drag & drop altogether
(for Dolphin, for example) saying that "users can just do Ctrl+C/X & Ctrl+V".

Anyway, if this is how we are 'fixing' this bug, please close it as WONTFIX
rather than FIXED. Because that's what's happening to this bug report. No
offense.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 36065] dragging from a window should not raise it

[Syam via KDE Bugzilla]

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

--- Comment #44 from Syam  ---
(In reply to Martin Gräßlin from comment #42)
> 
> So far we concluded that the best approach is to implement a raise on hover
> approach. As soon as the mouse enters another window during drag that one
> will be raised to give a clear field for the drop.

I'm not sure if that'd suffice. Consider the situation:
1. The 'source' window is behind the 'destination' window initially
2. The source window would cover the destination window completely if it is
raised
3. Because the source window is behind the destination window initially, the
destination window is visible
4. Now the user wants to drag something from the source window to the
destination window
5. The user starts to drag some item from the source window.
6. If the source window is raised, the destination window is no longer visible
so 'hovering' over it is not possible!

PS: I am extremely happy to see this bug being worked up on. Thanks a million
for all the great work you guys are doing.

-- 
You are receiving this mail because:
You are watching all bug changes.

[ark] [Bug 359049] New: Extracting a file by drag and drop from a ZIP archive creates the whole directory structure

[Syam via KDE Bugzilla]

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

Bug ID: 359049
   Summary: Extracting a file by drag and drop from a ZIP archive
creates the whole directory structure
   Product: ark
   Version: 2.19
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: elvis.angelac...@kdemail.net
  Reporter: get.so...@gmail.com
CC: rak...@freebsd.org

Selecting a single file from a zip archive and trying to extract it by drag &
drop to a Dolphin window, creates the whole directory structure. This doesn't
happen for tar.bz2 or tar.gz archives where only the selected file is created.
The observation is same as bug#208384, but it now happens only with zip files.
Haven't tried with 7z or other formats.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 353195] Copy error for folders with mixed files & folders in Split View

[Syam via KDE Bugzilla]

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

Syam  changed:

   What|Removed |Added

 CC||get.so...@gmail.com

--- Comment #14 from Syam  ---
I hit this bug while doing something exactly as described in comment #13.
Fedora 23 x86-64, 
Dolphin Version 15.08.1
KDE Frameworks 5.18.0
Qt 5.5.1 (built against 5.5.1)

-- 
You are receiving this mail because:
You are watching all bug changes.