Move "Details" tab to second place in Properties dialog
AbandonedPublic

Authored by mthw on Sep 13 2019, 11:42 AM.

Details

Reviewers
ngraham
cfeck
pino
Group Reviewers
Dolphin
Frameworks
VDG
Summary

From bugtracker:

Based on it's content it makes more sense to have it after right after "General". Also if the tabs are supposed to be sorted by most
used, then it surely shouldn't be at the end.

After:

FEATURE: 411861

Diff Detail

Repository
R241 KIO
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 16479
Build 16497: arc lint + arc unit
mthw created this revision.Sep 13 2019, 11:42 AM
Restricted Application added a project: Frameworks. · View Herald TranscriptSep 13 2019, 11:42 AM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
mthw requested review of this revision.Sep 13 2019, 11:42 AM
mthw edited the summary of this revision. (Show Details)Sep 13 2019, 11:45 AM
mthw added a reviewer: Dolphin.
mthw added a project: Dolphin.
mthw edited the summary of this revision. (Show Details)Sep 13 2019, 11:49 AM
GB_2 added a project: VDG.
GB_2 added subscribers: Frameworks, Dolphin, VDG.
GB_2 added a subscriber: GB_2.

+1
Next time please also add VDG as a subsriber and reviewer if there is a UI related change :-)

ngraham requested changes to this revision.Sep 13 2019, 12:48 PM
ngraham added a subscriber: ngraham.

+1 for the general idea. However this implementation only incidentally does what you want it to do. I apologize for steering you this way in the bug report, because it looks a bit more complicated than I thought, and we may have to puzzle through a more complex change.

So right now, the ordering goes like this:

  • General tab
  • Permissions tab
  • Checksums tab
  • Auto-generated tabs that depend on the context (of which Details is one)

So if we just move the auto-generated section to the second position, we can't actually guarantee that Details always comes first in that list.

What you could maybe do is add a new function KPropertiesDialog::insertPluginAt() that takes an int value index and inserts the plugin at that position in the index with d->m_pageList.insert(index, plugin);, then around line 628, check to see if the plugin we've just created is the Details plugin, and use the new function to specifically insert it at index 1 (which is position 2 since we start counting from zero).

Does that sound like a plan? I'll be happy to help you through it!

This revision now requires changes to proceed.Sep 13 2019, 12:48 PM
mthw updated this revision to Diff 65986.Sep 13 2019, 1:04 PM

Do you mean something like this? Only a wild guess, C lang is not my strength.

mthw added a comment.Sep 13 2019, 1:07 PM

I didn't know what to do with this

...check to see if the plugin we've just created is the Details plugin,...

Also the "Generator" should probably go back where it was right?

More or less! A new things:

  1. Don't forget to add the function definition for KPropertiesDialog::insertPluginAt(KPropertiesDialogPlugin *plugin, int index) to the header file
  2. Revert the change where you moved that section; it's now unnecessary
  3. Instead of unconditionally doing q->insertPluginAt(plugin, 1);, you'd want to do something more like this:
if (plugin == "details"  /* this is pseudocode */) {
    q->insertPluginAt(plugin, 1);
} else {
    q->insertPlugin(plugin);
}

I'm actually not sure how to check for what the plugin is though. Maybe someone from Frameworks can help.

mthw updated this revision to Diff 65988.Sep 13 2019, 1:32 PM

Changes made, if clause still not there

mthw updated this revision to Diff 66003.Sep 13 2019, 4:14 PM

Don't move the commented-out code, better description in header, formatting.

mthw added a comment.Sep 27 2019, 3:06 PM
  1. Instead of unconditionally doing q->insertPluginAt(plugin, 1);, you'd want to do something more like this:
if (plugin == "details"  /* this is pseudocode */) {
    q->insertPluginAt(plugin, 1);
} else {
    q->insertPlugin(plugin);
}

I'm actually not sure how to check for what the plugin is though. Maybe someone from Frameworks can help.

This is mostly done but we still need to do this the check, but neither me nor @ngraham know how to do it.

mthw added a comment.Oct 11 2019, 8:55 AM

Any progress on this?

meven added a subscriber: meven.Mar 9 2020, 7:42 AM
In D23926#538778, @mthw wrote:
  1. Instead of unconditionally doing q->insertPluginAt(plugin, 1);, you'd want to do something more like this:
if (plugin == "details"  /* this is pseudocode */) {
    q->insertPluginAt(plugin, 1);
} else {
    q->insertPlugin(plugin);
}

I'm actually not sure how to check for what the plugin is though. Maybe someone from Frameworks can help.

This is mostly done but we still need to do this the check, but neither me nor @ngraham know how to do it.

An alternative would be to move the whole block inserting KPropertiesDialog/Plugin before "KChecksumsPlugin".
AFAIK there are only two KPropertiesDialog/Plugin, so this would move details and baloo both of before the rest, which is fine IMO.
You would not need an integer parameter to insertPluginAt anymore.

src/widgets/kpropertiesdialog.cpp
586 ↗(On Diff #65986)

Not needed, if you could remove

mthw added a comment.Mar 9 2020, 3:34 PM

@meven So, the first version of this diff is good enough?

meven added a comment.Mar 9 2020, 9:55 PM
In D23926#624753, @mthw wrote:

@meven So, the first version of this diff is good enough?

Well no I missed @ngraham points that still stands.
And your current code result with the same effect anyway as long as we miss the condition "only if details plugin"

We don't have a "clean" way to do this.
One way to do the trick would be to look at the KService::Ptr &ptr icon() which will return "baloo" or the storageId() that should give "baloofilepropertiesplugin.desktop" for the baloo details plugin.
The storageId method should be preferred as less likely to change.

if (ptr->serviceId() == QStringLitteral("baloofilepropertiesplugin")) {
    q->insertPluginAt(plugin,1);
} else {
    q->insertPlugin(plugin);
}

Should be close enough to a working somewhat satisfying solution

I hope this helps.

mthw updated this revision to Diff 77388.Mar 11 2020, 7:59 AM
  • Made recomemded changes

This needs a rebase.

src/widgets/kpropertiesdialog.cpp
619 ↗(On Diff #65986)

space before the comma

mthw updated this revision to Diff 77445.Mar 11 2020, 6:07 PM

I don't really know how to do a rebase propertly so I hope I managed to do the same manually.

ngraham requested changes to this revision.Mar 11 2020, 6:21 PM

For future reference, you can rebase like so:

git fetch
git rebase origin/master

Also please make sure your code at least compiles before submitting a patch or a change to an existing patch.

src/widgets/kpropertiesdialog.cpp
619 ↗(On Diff #65986)
/home/nate/kde/src/kio/src/widgets/kpropertiesdialog.cpp:645:18: error: ‘class KService’ has no member named ‘serviceId’

QStringLiteral

src/widgets/kpropertiesdialog.h
251 ↗(On Diff #77445)

missing the semicolon

This revision now requires changes to proceed.Mar 11 2020, 6:21 PM
mthw updated this revision to Diff 77450.EditedMar 11 2020, 6:57 PM

Sorry about that, I should have checked what I am sending.

ngraham added inline comments.Mar 11 2020, 7:43 PM
src/widgets/kpropertiesdialog.cpp
619 ↗(On Diff #65986)

Build failure from this issue is not resolved yet

src/widgets/kpropertiesdialog.h
251 ↗(On Diff #77450)

Remove KPropertiesDialog:: from this function definition

mthw abandoned this revision.Apr 20 2020, 11:01 AM

I don't have the time (nor skill really) to work on this. Feel free to take over if you want to.