Re: Review Request: Konqueror: Ask for session restore ONLY on plain startup (not for every window)
> On Aug. 29, 2011, 4:09 p.m., David Faure wrote:
> > konqueror/src/konqmain.cpp, line 125
> > <http://git.reviewboard.kde.org/r/101850/diff/1/?file=26095#file26095line125>
> >
> > So it won't ask when logging into a new KDE session? Seems to me that
> > this could be kept here, no? It's not what you have been annoyed with ("on
> > every popup").
Ok, although i consider it superfluous to ask for restoring crashed sessions in
case a valid session can be restored, but that's just my personal preference.
> On Aug. 29, 2011, 4:09 p.m., David Faure wrote:
> > konqueror/src/konqmisc.cpp, line 119
> > <http://git.reviewboard.kde.org/r/101850/diff/1/?file=26096#file26096line119>
> >
> > If you don't offer restoration when opening a new URL, then offering
> > that only on process startup is not enough. When using preloading (and
> > especially if one sets the use of preloading to "always"), then there is
> > never a new process started, it's all in one process, and kfmclient simply
> > talks to the running konqueror. So you would never offer restoration.
> >
> > It seems to me that you would like it to run when "clicking on the
> > konqueror icon only", but that icon is usually wired to kfmclient, not to
> > konqueror directly. So it's kind of hard to make a difference, unless you
> > add a different command-line switch to kfmclient which could then, when
> > talking to a running konqueror, start by calling the "ask user" via DBus...
> >
> /usr/share/kde4/services/konqueror.desktop:Exec=konqueror %U
> /usr/share/applications/kde4/Home.desktop:Exec=kfmclient openProfile
> filemanagement
> /usr/share/autostart/konqy_preload.desktop:Exec=konqueror --preload
I always use the first but i see your point (i do not use preload because of
past stability issues)...
So how about a static 'userHasBeenAsked' var in
KonqMisc::createBrowserWindowFromProfile?
Imho this window really should be shown only once, and as you mentioned only
when konqy is launched by itself...
- Marcel
-----------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101850/#review6144
---
On July 4, 2011, 11:44 p.m., Marcel Partap wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101850/
> ---
>
> (Updated July 4, 2011, 11:44 p.m.)
>
>
> Review request for KDE Base Apps and David Faure.
>
>
> Summary
> ---
>
> This patch stops asking for session restore for EVERY new window (popups!)
> and does so ONLY when initial konqueror process is started, and called
> without URL. Because i didn't want to loose all my crashed sessions and the
> 'import crashed sessions as bookmarks' feature disappeared sometime, i had
> been clicking on 'ask again later' 42 bazillion times. Restoring all the
> crashed sessions always brought down the process (imho each session should
> restore as individual process, but that is another patch).
>
>
> Diffs
> -
>
> konqueror/src/konqmain.cpp 218e708
> konqueror/src/konqmisc.cpp c46dc07
>
> Diff: http://git.reviewboard.kde.org/r/101850/diff
>
>
> Testing
> ---
>
> Tryed out and traced everything with GDB, does as says. Finally no huge
> crashed-session-parsing-delay for every stupid popup ^^
>
>
> Thanks,
>
> Marcel
>
>
Re: Review Request: fix #277269 Dolphin(Part) Detail/Tree view, highlighted selection paint glitch
> On July 20, 2011, 3:29 p.m., Peter Penz wrote: > > Thanks for the update! > > > > >> would only make sense to push it to the 4.7 branch. > > > What exactly do you mean by 'only'? Isn't 4.7 the branch just > > > about to be released and which will be in all distros until sometime next > > > year? > > > > I meant that this change should only be pushed to the KDE/4.7 and not to > > master as this class will be removed from master around the beginning of > > August (Dolphin 2.0...) Hi Peter, sorry was busy with uni stuff.. could you please take care of applying this to the correct branch? i don't want to mess up the git.. looking forward to see the new branch evolving... (from its currently somewhat disfunctional state.. really need that file selection 'feature' *g) - Marcel --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101924/#review4903 --- On July 20, 2011, 2:23 p.m., Marcel Partap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101924/ > --- > > (Updated July 20, 2011, 2:23 p.m.) > > > Review request for KDE Base Apps, David Faure and Peter Penz. > > > Summary > --- > > What was strange that background highlighting and actual item selection were > drawn independently from each other and the bogus highlighting to the left of > the item was not cleared... Now this one was a __REAL__ bitch to get dealt > with, took me hours and hours bashing my head against the shell ^^ > ok now again the viewOptions is not only not the place to turn off background > highlighting, but there it was even tried to ENABLE it :O > turned out this so called QStyle::SH_ItemView_ShowDecorationSelected > documented as "When an item in an item view is selected, also highlight the > branch or other decoration." is hard-coded on by DEFAULT in QCommonStyle and > all inheriting from there so it requires a QProxyStyle to override the > setting. While we have the opportunity, also set > SH_ItemView_ArrowKeysNavigateIntoChildren for added joice of keyboard > navigation (although strange effect comes up when being on a leaf and > pressing Cursor::Right again - but with or without this setting, something > with the selection handler...) > ...now someone owes me CAKE for this one :D > > > Diffs > - > > dolphin/src/views/dolphindetailsview.cpp 0ce26df > dolphin/src/views/dolphintreeview.h c037d41 > dolphin/src/views/dolphintreeview.cpp 64b66aa > > Diff: http://git.reviewboard.kde.org/r/101924/diff > > > Testing > --- > > head-bashing > > > Screenshots > --- > > dolphin-treeview-selection-paint-fail > http://git.reviewboard.kde.org/r/101924/s/195/ > > > Thanks, > > Marcel > >
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Where's the problem? Have the release tarballs already and irrevocably been forged and fed into some unstoppable mechanism? Per the KDE Release Schedule, we are frozen for everything except build compilation failures, as the KDE 4.7.0 release process is underway. So what is the better option here, violate rules to prevent any users from 'suffering' - or for no meaningful reason (besides 'discipline') strictly adhering to that self-imposed code of conduct and finding ways to cope with the implications that might have? Have you asked 4.7 release manager about it? It would come as a big surprise if anyone would be going to file an official complaint for breaching the freeze for this very valid reason. I really doubt anyone is going to 'suffer'... They will. Will not, because the KDE team will act with common sense, of course. Experience Freedom! The KDE® Community is an international technology team dedicated to creating a free and user-friendly computing experience
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
KDE 4.7 will probably be shipped by distributions alongside GNOME 3.0. A short term solution is required at the bare minimum to fix that - which can be done as I noted. Where's the problem? Have the release tarballs already and irrevocably been forged and fed into some unstoppable mechanism? On 23/07/11 00:25, Shaun McCance wrote: Name=System Settings OnlyShowIn=KDE The other looks like this: Name=KDE System Settings NotShowIn=KDE Why not just SVN_SILENTly add these tree lines in the .desktop file and include in 4.7 gold? Two more days seem to give plenty time for that. Otherwise our users will be the ones who will suffer. I really doubt anyone is going to 'suffer'... This NamingClashCrisis is more ridiculous ego tussle then a real problem. For comparison, hunger crisis in Somalia is a real problem where people actually do suffer. #peace/marcel.
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
Still, we should treat each other with respect. [...] being angry doesn't solve problems, especially not when communication about a common solution is required. [...] Not everything can be done easily, but we should look for the right solutions and persue them. There is no established mechanism to rate mailing list posts, but i'd mod this one up. (:
Re: Review Request: fix for #277372 - dolphin part looses view state on every tab change
> On July 11, 2011, 9 p.m., Peter Penz wrote: > > Thanks for the patch, looks good! > > Peter Penz wrote: > Committed to 4.7 (is already fixed for Dolphin 2.0 that will get merged > to master around beginning of August) still nothing pushed to public repo. huh? (: - Marcel --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101919/#review4616 --- On July 11, 2011, 8:45 p.m., Marcel Partap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101919/ > --- > > (Updated July 11, 2011, 8:45 p.m.) > > > Review request for KDE Base Apps, David Faure and Peter Penz. > > > Summary > --- > > At the point where m_viewModeController->setUrl(url) was invoked in current > code, the view does not yet exist because it is only created in > applyViewProperties(). Moving the call after view creation is not enough > however. The DolphinView's url itself has to be set, that implies setting the > url of the VMC. Correcting this makes the showEvent() hack unnecessary. > > > Diffs > - > > dolphin/src/views/dolphinview.h 48967e6 > dolphin/src/views/dolphinview.cpp 681ce74 > > Diff: http://git.reviewboard.kde.org/r/101919/diff > > > Testing > --- > > > Thanks, > > Marcel > >
Re: Review Request: fix #277269 Dolphin(Part) Detail/Tree view, highlighted selection paint glitch
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101924/ --- (Updated July 20, 2011, 2:23 p.m.) Review request for KDE Base Apps, David Faure and Peter Penz. Changes --- This should have the proxy style destroyed with the treeview instead of leaking it. > would only make sense to push it to the 4.7 branch. What exactly do you mean by 'only'? Isn't 4.7 the branch just about to be released and which will be in all distros until sometime next year? Or am i the only one who has this? couldn't find a bug report about it. Anyways. Also have got my git setup now in case you can't be bothered typing a commit message :) Summary --- What was strange that background highlighting and actual item selection were drawn independently from each other and the bogus highlighting to the left of the item was not cleared... Now this one was a __REAL__ bitch to get dealt with, took me hours and hours bashing my head against the shell ^^ ok now again the viewOptions is not only not the place to turn off background highlighting, but there it was even tried to ENABLE it :O turned out this so called QStyle::SH_ItemView_ShowDecorationSelected documented as "When an item in an item view is selected, also highlight the branch or other decoration." is hard-coded on by DEFAULT in QCommonStyle and all inheriting from there so it requires a QProxyStyle to override the setting. While we have the opportunity, also set SH_ItemView_ArrowKeysNavigateIntoChildren for added joice of keyboard navigation (although strange effect comes up when being on a leaf and pressing Cursor::Right again - but with or without this setting, something with the selection handler...) ...now someone owes me CAKE for this one :D Diffs (updated) - dolphin/src/views/dolphindetailsview.cpp 0ce26df dolphin/src/views/dolphintreeview.h c037d41 dolphin/src/views/dolphintreeview.cpp 64b66aa Diff: http://git.reviewboard.kde.org/r/101924/diff Testing --- head-bashing Screenshots --- dolphin-treeview-selection-paint-fail http://git.reviewboard.kde.org/r/101924/s/195/ Thanks, Marcel
Re: Review Request: Konqueror: Ask for session restore ONLY on plain startup (not for every window)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101850/#review4860 --- Uhhmm.. so can i commit this? David? .. (: - Marcel On July 4, 2011, 11:44 p.m., Marcel Partap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101850/ > --- > > (Updated July 4, 2011, 11:44 p.m.) > > > Review request for KDE Base Apps and David Faure. > > > Summary > --- > > This patch stops asking for session restore for EVERY new window (popups!) > and does so ONLY when initial konqueror process is started, and called > without URL. Because i didn't want to loose all my crashed sessions and the > 'import crashed sessions as bookmarks' feature disappeared sometime, i had > been clicking on 'ask again later' 42 bazillion times. Restoring all the > crashed sessions always brought down the process (imho each session should > restore as individual process, but that is another patch). > > > Diffs > - > > konqueror/src/konqmain.cpp 218e708 > konqueror/src/konqmisc.cpp c46dc07 > > Diff: http://git.reviewboard.kde.org/r/101850/diff > > > Testing > --- > > Tryed out and traced everything with GDB, does as says. Finally no huge > crashed-session-parsing-delay for every stupid popup ^^ > > > Thanks, > > Marcel > >
Re: Review Request: DolphinDetailsView: fix column auto size fail on custom font styles
> On July 11, 2011, 9:38 p.m., Peter Penz wrote: > > Thanks for the patch! It looks good, but it only makes sense to push it to > > the 4.7 branch: For master Dolphin 2.0 will be integrated until beginning > > of August which has a new view-engine that makes this patch obsolete. If > > you plan to do further fixes for the icons-, details- or column-view (or > > related classes) please contact me directly before as most probably the > > patches are not compatible with the new view-engine. omfg lolbbq ^^ well please commit these fixes, my last commit is ages ago and was on SVN, have never done it with git.. #best - Marcel --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101923/#review4618 --- On July 11, 2011, 9:25 p.m., Marcel Partap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101923/ > --- > > (Updated July 11, 2011, 9:25 p.m.) > > > Review request for KDE Base Apps, David Faure and Peter Penz. > > > Summary > --- > > The auto-calculated width of columns always is same regardless of custom font > style so there was sure something wrong.. > => Setting the font in the viewOptions() actually has no effect on either > viewport or view, has to be done via setFont(). So > - adding setFont(m_font) in view init phase > - removing font stuff from viewOptions() and NOOP assignment in > slotGlobalSettingsChanged() > - avoiding extra inter-object calls by using m_font directly > Also replaced abusing fontMetrics.height for horizontalGap - by coincidence > it was more then needed, but for bigger fonts might be 20px and up while > usually only 10px is needed. Pixel-perfect calculation required DEEP > tracing throughout QT style rendering stuff - (PM_FocusFrameHMargin+1)*2 > seems to be the way it is calculated, +const 4 which is hard-coded all over > the place though. > > > Diffs > - > > dolphin/src/views/dolphindetailsview.cpp 0ce26df > > Diff: http://git.reviewboard.kde.org/r/101923/diff > > > Testing > --- > > cgdb tracing aaall day long ^^ > > > Thanks, > > Marcel > >
Review Request: fix #277269 Dolphin(Part) Detail/Tree view, highlighted selection paint glitch
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101924/ --- Review request for KDE Base Apps, David Faure and Peter Penz. Summary --- What was strange that background highlighting and actual item selection were drawn independently from each other and the bogus highlighting to the left of the item was not cleared... Now this one was a __REAL__ bitch to get dealt with, took me hours and hours bashing my head against the shell ^^ ok now again the viewOptions is not only not the place to turn off background highlighting, but there it was even tried to ENABLE it :O turned out this so called QStyle::SH_ItemView_ShowDecorationSelected documented as "When an item in an item view is selected, also highlight the branch or other decoration." is hard-coded on by DEFAULT in QCommonStyle and all inheriting from there so it requires a QProxyStyle to override the setting. While we have the opportunity, also set SH_ItemView_ArrowKeysNavigateIntoChildren for added joice of keyboard navigation (although strange effect comes up when being on a leaf and pressing Cursor::Right again - but with or without this setting, something with the selection handler...) ...now someone owes me CAKE for this one :D Diffs - dolphin/src/views/dolphindetailsview.cpp 0ce26df dolphin/src/views/dolphintreeview.h c037d41 dolphin/src/views/dolphintreeview.cpp 64b66aa Diff: http://git.reviewboard.kde.org/r/101924/diff Testing --- head-bashing Screenshots --- dolphin-treeview-selection-paint-fail http://git.reviewboard.kde.org/r/101924/s/195/ Thanks, Marcel
Review Request: DolphinDetailsView: fix column auto size fail on custom font styles
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101923/ --- Review request for KDE Base Apps, David Faure and Peter Penz. Summary --- The auto-calculated width of columns always is same regardless of custom font style so there was sure something wrong.. => Setting the font in the viewOptions() actually has no effect on either viewport or view, has to be done via setFont(). So - adding setFont(m_font) in view init phase - removing font stuff from viewOptions() and NOOP assignment in slotGlobalSettingsChanged() - avoiding extra inter-object calls by using m_font directly Also replaced abusing fontMetrics.height for horizontalGap - by coincidence it was more then needed, but for bigger fonts might be 20px and up while usually only 10px is needed. Pixel-perfect calculation required DEEP tracing throughout QT style rendering stuff - (PM_FocusFrameHMargin+1)*2 seems to be the way it is calculated, +const 4 which is hard-coded all over the place though. Diffs - dolphin/src/views/dolphindetailsview.cpp 0ce26df Diff: http://git.reviewboard.kde.org/r/101923/diff Testing --- cgdb tracing aaall day long ^^ Thanks, Marcel
Review Request: fix for #277372 - dolphin part looses view state on every tab change
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101919/ --- Review request for KDE Base Apps, David Faure and Peter Penz. Summary --- At the point where m_viewModeController->setUrl(url) was invoked in current code, the view does not yet exist because it is only created in applyViewProperties(). Moving the call after view creation is not enough however. The DolphinView's url itself has to be set, that implies setting the url of the VMC. Correcting this makes the showEvent() hack unnecessary. Diffs - dolphin/src/views/dolphinview.h 48967e6 dolphin/src/views/dolphinview.cpp 681ce74 Diff: http://git.reviewboard.kde.org/r/101919/diff Testing --- Thanks, Marcel
Review Request: Konqueror: Ask for session restore ONLY on plain startup (not for every window)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101850/ --- Review request for KDE Base Apps and David Faure. Summary --- This patch stops asking for session restore for EVERY new window (popups!) and does so ONLY when initial konqueror process is started, and called without URL. Because i didn't want to loose all my crashed sessions and the 'import crashed sessions as bookmarks' feature disappeared sometime, i had been clicking on 'ask again later' 42 bazillion times. Restoring all the crashed sessions always brought down the process (imho each session should restore as individual process, but that is another patch). Diffs - konqueror/src/konqmain.cpp 218e708 konqueror/src/konqmisc.cpp c46dc07 Diff: http://git.reviewboard.kde.org/r/101850/diff Testing --- Tryed out and traced everything with GDB, does as says. Finally no huge crashed-session-parsing-delay for every stupid popup ^^ Thanks, Marcel
Re: Review Request: konqueror: reset URL when pressing ESC in address bar
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6681/ --- (Updated July 4, 2011, 11:29 p.m.) Review request for kdelibs and David Faure. Changes --- Patch v4, slimmed down to bare simplicity. > The URL restored needs to be what was originally entered when the page was > rendered. > For example, if I typed "about:plugins" to view the available plugins, then > typed another > address and pressed escape, the address I expect to see is "about:blank" and > not a > blank location bar, which unfortunately is what this patch will result in. Actually, I don't think so. To hide the real URL for about:konqueror and about:blank on initial opening is ok, but if you press ESCAPE, you get the current view's real URL. Imho that makes more sense than adding another variable to track the originally entered URL, which would complicate this simply beyond any sanity to catch and differentiate all corner cases. Summary --- Attempted patch to make konqueror reset the URL when escape is pressed in the address bar. For reasons beyond my grokledge does not always seem to work. This addresses bug 257841. https://bugs.kde.org/show_bug.cgi?id=257841 Diffs (updated) - /trunk/KDE/kdebase/apps/konqueror/src/konqmainwindow.cpp 1200388 Diff: http://svn.reviewboard.kde.org/r/6681/diff Testing --- see https://bugs.kde.org/show_bug.cgi?id=257841#c0 Thanks, Marcel
Re: Review Request: konqueror: reset URL when pressing ESC in address bar
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6681/ --- (Updated June 21, 2011, 4:20 p.m.) Review request for kdelibs and David Faure. Changes --- > I think this should be m_currentView->locationBarURL() Cannot be used, equals the combo box entry after tab change. > If you then simply press escape in location bar, the location bar switches to > "about:konqueror" because that is the url of the current view. In fact, i'd consider that sane behaviour. However, it has been dealt with ;) btw the code above the patch is defunct. Shouldn't it rather call slotNextTab()/slotPrevTab? no reverse CTRL+TABbing as of now. Summary --- Attempted patch to make konqueror reset the URL when escape is pressed in the address bar. For reasons beyond my grokledge does not always seem to work. This addresses bug 257841. https://bugs.kde.org/show_bug.cgi?id=257841 Diffs (updated) - /trunk/KDE/kdebase/apps/konqueror/src/konqmainwindow.cpp 1200388 Diff: http://svn.reviewboard.kde.org/r/6681/diff Testing --- see https://bugs.kde.org/show_bug.cgi?id=257841#c0 Thanks, Marcel
Re: Review Request: konqueror: reset URL when pressing ESC in address bar
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6681/ --- (Updated June 21, 2011, 11:26 a.m.) Review request for kdelibs and David Faure. Changes --- And here a cleaned and sanitized version of the patch. Using the stopSlot will NOT work because the stop action is always disabled, except while loading a view. So it has to be the event filter. Summary --- Attempted patch to make konqueror reset the URL when escape is pressed in the address bar. For reasons beyond my grokledge does not always seem to work. This addresses bug 257841. https://bugs.kde.org/show_bug.cgi?id=257841 Diffs (updated) - /trunk/KDE/kdebase/apps/konqueror/src/konqmainwindow.cpp 1200388 Diff: http://svn.reviewboard.kde.org/r/6681/diff Testing --- see https://bugs.kde.org/show_bug.cgi?id=257841#c0 Thanks, Marcel
Review Request: konqueror: reset URL when pressing ESC in address bar
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6681/ --- Review request for kdelibs and David Faure. Summary --- Attempted patch to make konqueror reset the URL when escape is pressed in the address bar. For reasons beyond my grokledge does not always seem to work. This addresses bug 257841. https://bugs.kde.org/show_bug.cgi?id=257841 Diffs - /trunk/KDE/kdebase/apps/konqueror/src/konqmainwindow.cpp 1200388 Diff: http://svn.reviewboard.kde.org/r/6681/diff Testing --- see https://bugs.kde.org/show_bug.cgi?id=257841#c0 Thanks, Marcel
Re: Qt5 -> KDE5?
Hi there, on this occasion where future direction of KDE is being defined, here's just a note from a linux 'power user' who turned from full KDE (3.5) fanboyness to using xfce, coping with some kde apps (yakuake, konqueror, okular, the games)... - Do we want "KDE 5" to be a big change, or just a small increment? Do we need a big change? I don't think so - we are already fantastic :) although you put a smiley there, _this_ attitude is what i perceive as a huge problem regarding current KDE. The continuing 'pareto UI design frenzy', i.e. designing for the fictitious 80% collective of Joe-users(*) has been a real turn off to me. But the real problem behind that is that often, even elaborate users have no choice of changing stuff they'd like to behave differently (besides locally applying hacky patches). Fortunately, QML offers a great way out: separating GUI definition from the code providing features. This could result in what i'd dream of as great solution - UI style sheets, for joes, advanced users or kids. That's a long way off though. Another thing, the handling of bug reports could be a bit more mature in some cases. Flagging users UI improvement proposals as RESOLVED/WONTFIX (**) or pretending loss of user data under special conditions is not a problem that could be dealt with (***) is not what i'd consider super responsible maintainership... but then again i stopped reporting bugs anyways out of demotivation... Not to play the blame game here, i still have hopes KDE can be the fun 'kool' power experience KDE 3.5 was, but my euphoric 4.x expectations have largely been smashed by instability, imho poor UI decisions and a plasma dream that never materialized. That said, will continue compiling QT/KDE trunk regularly and see what innovative new solutions you guys (hopefully) come up with! (: #regards/marcel. (*) why at all is there a debate wether users should be able to rename files from file open/save dialogs? dialog text made non-selectable for no good reasons, forcing manual transfer of alert messages to search engine boxes.. non-resizable modal dialogs with scroll bars or ellipses? a silly more button in download dialogues taking just as much space as the information it hides.. list goes on. (**) https://bugs.kde.org/show_bug.cgi?id=183774 (***) https://bugs.kde.org/show_bug.cgi?id=265567
