from:"Friedrich W. H. Kossebau"

Am Mittwoch, 15. Januar 2014, 12:14:59 schrieb David Faure:
 On Wednesday 15 January 2014 11:01:55 Friedrich W. H. Kossebau wrote:
  Guess you already started to tackle that? :) Or should I give it a try
  tonight?
 
 Go ahead :)

Some questions while I go ahead:

1. How should own headers be included, what is preferred?
#include kparts/part.h
or 
#include part.h

And both the same in the public headers and in the normal sources? Myself I 
also use the second version, but I found a mixture in use, so wonder if one is 
preferred/recommended in the frameworks.


2. How to do KDE4-compatibility for moved header content?

E.g. in event.h for KDE4-compatibility the declarations which have been moved 
to their own headers would need to be pulled in again, at least for builds 
using KDE4Support
Is that done by having includes in the normal file, guarded by a flag, like

// KDE4 compat
#if KDE4COMPATIBLE
#include kparts/guiactivateevent.h
#include kparts/partactivateevent.h
#include kparts/partselectevent.h
#endif

If so, which flag?

Or is there another way?

Cheers
Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 115047: Fix substitution order for some KUIT elements with attributes


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115047/
---

(Updated Jan. 16, 2014, 9:37 p.m.)


Review request for KDE Frameworks and Chusslove Illich.


Changes
---

Extended unit test with more or less the examples for semantic tags found at 
http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics, 
covering also link/, email/, warning/, note/.
Marked two TODOs for unrelated issues I found adding more tests. Separate 
issues, so not handled in this patch.


Repository: ki18n


Description
---

After fixing the DrKonqi dialog texts to use xi18n calls where needed I found 
that for link elements the url and the description text are used in swapped 
order when the link element is substituted. Looking into kuitmarkup.cpp I 
found that...
a) indeed for some elements the value of the attribute was expected to be the 
first argument (%1) on substitution, while for others it was expected to be the 
second (%2) (note, warning, link)
b) for some elements also the attribute name used in the comment was not 
matching the actual attribute name (link, email

Comparing to the old kuitsemantics.cpp that seems a 1:1 porting. Strange that 
it worked with kdelibs4. Did the translations possibly have the order fixed 
where needed? Or had the old SET_PATTERN macro a different handling (did not 
investigate that, only the new)?

In any case, the attached patch fixes the order of attributes where it seemed 
needed (to fix a)) and aligned the comments with the actual attribute names 
where needed (to fix b)).

The result should then match the current tutorial at 
http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics


Diffs (updated)
-

  autotests/klocalizedstringtest.cpp 30f5bc1 
  src/kuitmarkup.cpp fa76e5f 

Diff: https://git.reviewboard.kde.org/r/115047/diff/


Testing (updated)
---

DrKonqi dialogs get proper links with the patch used.
And all existing and new autotests pass as expected.


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 115047: Fix substitution order for some KUIT elements with attributes


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115047/
---

(Updated Jan. 16, 2014, 11:26 p.m.)


Review request for KDE Frameworks and Chusslove Illich.


Changes
---

Added proposed first-aid fix, worked for me.


Repository: ki18n


Description
---

After fixing the DrKonqi dialog texts to use xi18n calls where needed I found 
that for link elements the url and the description text are used in swapped 
order when the link element is substituted. Looking into kuitmarkup.cpp I 
found that...
a) indeed for some elements the value of the attribute was expected to be the 
first argument (%1) on substitution, while for others it was expected to be the 
second (%2) (note, warning, link)
b) for some elements also the attribute name used in the comment was not 
matching the actual attribute name (link, email

Comparing to the old kuitsemantics.cpp that seems a 1:1 porting. Strange that 
it worked with kdelibs4. Did the translations possibly have the order fixed 
where needed? Or had the old SET_PATTERN macro a different handling (did not 
investigate that, only the new)?

In any case, the attached patch fixes the order of attributes where it seemed 
needed (to fix a)) and aligned the comments with the actual attribute names 
where needed (to fix b)).

The result should then match the current tutorial at 
http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics


Diffs (updated)
-

  autotests/klocalizedstringtest.h 9b663f5 
  autotests/klocalizedstringtest.cpp 30f5bc1 
  src/kuitmarkup.cpp fa76e5f 

Diff: https://git.reviewboard.kde.org/r/115047/diff/


Testing
---

DrKonqi dialogs get proper links with the patch used.
And all existing and new autotests pass as expected.


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 115047: Fix substitution order for some KUIT elements with attributes


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115047/
---

(Updated Jan. 16, 2014, 11:39 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Chusslove Illich.


Repository: ki18n


Description
---

After fixing the DrKonqi dialog texts to use xi18n calls where needed I found 
that for link elements the url and the description text are used in swapped 
order when the link element is substituted. Looking into kuitmarkup.cpp I 
found that...
a) indeed for some elements the value of the attribute was expected to be the 
first argument (%1) on substitution, while for others it was expected to be the 
second (%2) (note, warning, link)
b) for some elements also the attribute name used in the comment was not 
matching the actual attribute name (link, email

Comparing to the old kuitsemantics.cpp that seems a 1:1 porting. Strange that 
it worked with kdelibs4. Did the translations possibly have the order fixed 
where needed? Or had the old SET_PATTERN macro a different handling (did not 
investigate that, only the new)?

In any case, the attached patch fixes the order of attributes where it seemed 
needed (to fix a)) and aligned the comments with the actual attribute names 
where needed (to fix b)).

The result should then match the current tutorial at 
http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics


Diffs
-

  autotests/klocalizedstringtest.h 9b663f5 
  autotests/klocalizedstringtest.cpp 30f5bc1 
  src/kuitmarkup.cpp fa76e5f 

Diff: https://git.reviewboard.kde.org/r/115047/diff/


Testing
---

DrKonqi dialogs get proper links with the patch used.
And all existing and new autotests pass as expected.


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 115097: KParts: Move each class into its own header/source file pair

2014-01-17 Thread Friedrich W. H. Kossebau

/partbase.h PRE-CREATION 
  src/partbase.cpp PRE-CREATION 
  src/partbase_p.h PRE-CREATION 
  src/partmanager.h 624a97c 
  src/partmanager.cpp 7c1f3b0 
  src/partselectevent.h PRE-CREATION 
  src/partselectevent.cpp PRE-CREATION 
  src/plugin.h b7d130f 
  src/plugin.cpp 344f75b 
  src/readonlypart.h PRE-CREATION 
  src/readonlypart.cpp PRE-CREATION 
  src/readonlypart_p.h PRE-CREATION 
  src/readwritepart.h PRE-CREATION 
  src/readwritepart.cpp PRE-CREATION 
  src/readwritepart_p.h PRE-CREATION 
  src/scriptableextension.h 9cec71f 
  src/scriptableextension.cpp d31a558 
  src/scriptableextension_p.h 82808f7 
  src/selectorinterface.h PRE-CREATION 
  src/selectorinterface.cpp PRE-CREATION 
  src/statusbarextension.h c46fd55 
  src/statusbarextension.cpp 2d8de8a 
  src/textextension.h f8c77e4 
  src/textextension.cpp 3dc5a99 
  src/windowargs.h PRE-CREATION 
  autotests/parttest.cpp 7505948 
  src/CMakeLists.txt d987f46 
  src/browserarguments.h PRE-CREATION 
  src/browserarguments.cpp PRE-CREATION 
  src/browserextension.h 998f7ac 
  src/browserextension.cpp a367de9 
  src/browserhostextension.h PRE-CREATION 
  src/browserhostextension.cpp PRE-CREATION 
  src/browserinterface.h cf10499 

Diff: https://git.reviewboard.kde.org/r/115097/diff/


Testing
---

kdesrc-build/kf5-qt5-build-include builds fine for me with all the patches.


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 115098: Adapt KParts compat-forwarding headers to new one-header-per-class policy in KParts

2014-01-17 Thread Friedrich W. H. Kossebau


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115098/
---

Review request for KDE Frameworks and David Faure.


Repository: kde4support


Description
---

Counterpart to: https://git.reviewboard.kde.org/r/115097/

Main discussion over there, please.


Diffs
-

  src/includes/KParts/OpenUrlEvent c3e9e59 
  src/includes/KParts/Part bcb6c5e 
  src/includes/KParts/PartActivateEvent dabdd2f 
  src/includes/KParts/PartBase bcb6c5e 
  src/includes/KParts/PartManager 2dcfeb3 
  src/includes/KParts/PartSelectEvent dabdd2f 
  src/includes/KParts/Plugin f73168d 
  src/includes/KParts/ReadOnlyPart bcb6c5e 
  src/includes/KParts/ReadWritePart bcb6c5e 
  src/includes/KParts/StatusBarExtension 8c8a481 
  src/includes/KParts/TextExtension cb73ab5 
  src/includes/KParts/WindowArgs c3e9e59 
  src/kparts/listingextension.h PRE-CREATION 
  src/CMakeLists.txt 23b0d6d 
  src/includes/CMakeLists.txt 2b2130f 
  src/includes/KParts/BrowserExtension c3e9e59 
  src/includes/KParts/BrowserHostExtension c3e9e59 
  src/includes/KParts/BrowserInterface 640f47b 
  src/includes/KParts/BrowserRun b63479b 
  src/includes/KParts/Event dabdd2f 
  src/includes/KParts/FileInfoExtension 13c7c41 
  src/includes/KParts/GUIActivateEvent dabdd2f 
  src/includes/KParts/HistoryProvider b8c3fc9 
  src/includes/KParts/HtmlExtension aae280e 
  src/includes/KParts/ListingExtension 38598f9 
  src/includes/KParts/LiveConnectExtension c3e9e59 
  src/includes/KParts/MainWindow 452e115 

Diff: https://git.reviewboard.kde.org/r/115098/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 115098: Adapt KParts compat-forwarding headers to new one-header-per-class policy in KParts

2014-01-18 Thread Friedrich W. H. Kossebau



 On Jan. 18, 2014, 8:58 a.m., David Faure wrote:
  Why does this remove some forwarding headers?

Because they are installed from the KParts module itself already, with the same 
forwarding include path. So no need to duplicate them in KDE4Support, or?

(Only difference is those from KParts have '' around the path, not '' and 
''. This is a small error in ecm_generate_headers still, it needs to add ../ 
in front of the path in case of a prefixed path. Other option would be '' as 
well '', but a relative link seems safer to me)


- Friedrich W. H.


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115098/#review47627
---


On Jan. 18, 2014, 3:48 a.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115098/
 ---
 
 (Updated Jan. 18, 2014, 3:48 a.m.)
 
 
 Review request for KDE Frameworks and David Faure.
 
 
 Repository: kde4support
 
 
 Description
 ---
 
 Counterpart to: https://git.reviewboard.kde.org/r/115097/
 
 Main discussion over there, please.
 
 
 Diffs
 -
 
   src/includes/KParts/OpenUrlEvent c3e9e59 
   src/includes/KParts/Part bcb6c5e 
   src/includes/KParts/PartActivateEvent dabdd2f 
   src/includes/KParts/PartBase bcb6c5e 
   src/includes/KParts/PartManager 2dcfeb3 
   src/includes/KParts/PartSelectEvent dabdd2f 
   src/includes/KParts/Plugin f73168d 
   src/includes/KParts/ReadOnlyPart bcb6c5e 
   src/includes/KParts/ReadWritePart bcb6c5e 
   src/includes/KParts/StatusBarExtension 8c8a481 
   src/includes/KParts/TextExtension cb73ab5 
   src/includes/KParts/WindowArgs c3e9e59 
   src/kparts/listingextension.h PRE-CREATION 
   src/CMakeLists.txt 23b0d6d 
   src/includes/CMakeLists.txt 2b2130f 
   src/includes/KParts/BrowserExtension c3e9e59 
   src/includes/KParts/BrowserHostExtension c3e9e59 
   src/includes/KParts/BrowserInterface 640f47b 
   src/includes/KParts/BrowserRun b63479b 
   src/includes/KParts/Event dabdd2f 
   src/includes/KParts/FileInfoExtension 13c7c41 
   src/includes/KParts/GUIActivateEvent dabdd2f 
   src/includes/KParts/HistoryProvider b8c3fc9 
   src/includes/KParts/HtmlExtension aae280e 
   src/includes/KParts/ListingExtension 38598f9 
   src/includes/KParts/LiveConnectExtension c3e9e59 
   src/includes/KParts/MainWindow 452e115 
 
 Diff: https://git.reviewboard.kde.org/r/115098/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 115098: Adapt KParts compat-forwarding headers to new one-header-per-class policy in KParts

2014-01-19 Thread Friedrich W. H. Kossebau



 On Jan. 18, 2014, 8:58 a.m., David Faure wrote:
  Why does this remove some forwarding headers?
 
 Friedrich W. H. Kossebau wrote:
 Because they are installed from the KParts module itself already, with 
 the same forwarding include path. So no need to duplicate them in 
 KDE4Support, or?
 
 (Only difference is those from KParts have '' around the path, not '' 
 and ''. This is a small error in ecm_generate_headers still, it needs to add 
 ../ in front of the path in case of a prefixed path. Other option would be 
 '' as well '', but a relative link seems safer to me)
 
 David Faure wrote:
 But this is the case for most of the forwarding headers installed by 
 kde4support. They duplicate the ones installed by the frameworks.
 One reason is that the ones from kde4support go into include/KDE, so they 
 make old-style KDE/KParts/Part work, and the other reason is historical (we 
 had this before we had ecm_generate_header).

Ah, did not think of people using KDE/..., okay (though now I remember there 
was even a case with one of the fixes I prepared for the other programs). In 
that case I will also need to fix-up things for my recent commit to  
kde4support/src/includes/KNS3, as I removed most CamelCase-forwarding headers 
with the same (wrong) reasoning. Will update this patch as well in a few 
minutes.


- Friedrich W. H.


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115098/#review47627
---


On Jan. 18, 2014, 3:48 a.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115098/
 ---
 
 (Updated Jan. 18, 2014, 3:48 a.m.)
 
 
 Review request for KDE Frameworks and David Faure.
 
 
 Repository: kde4support
 
 
 Description
 ---
 
 Counterpart to: https://git.reviewboard.kde.org/r/115097/
 
 Main discussion over there, please.
 
 
 Diffs
 -
 
   src/includes/KParts/OpenUrlEvent c3e9e59 
   src/includes/KParts/Part bcb6c5e 
   src/includes/KParts/PartActivateEvent dabdd2f 
   src/includes/KParts/PartBase bcb6c5e 
   src/includes/KParts/PartManager 2dcfeb3 
   src/includes/KParts/PartSelectEvent dabdd2f 
   src/includes/KParts/Plugin f73168d 
   src/includes/KParts/ReadOnlyPart bcb6c5e 
   src/includes/KParts/ReadWritePart bcb6c5e 
   src/includes/KParts/StatusBarExtension 8c8a481 
   src/includes/KParts/TextExtension cb73ab5 
   src/includes/KParts/WindowArgs c3e9e59 
   src/kparts/listingextension.h PRE-CREATION 
   src/CMakeLists.txt 23b0d6d 
   src/includes/CMakeLists.txt 2b2130f 
   src/includes/KParts/BrowserExtension c3e9e59 
   src/includes/KParts/BrowserHostExtension c3e9e59 
   src/includes/KParts/BrowserInterface 640f47b 
   src/includes/KParts/BrowserRun b63479b 
   src/includes/KParts/Event dabdd2f 
   src/includes/KParts/FileInfoExtension 13c7c41 
   src/includes/KParts/GUIActivateEvent dabdd2f 
   src/includes/KParts/HistoryProvider b8c3fc9 
   src/includes/KParts/HtmlExtension aae280e 
   src/includes/KParts/ListingExtension 38598f9 
   src/includes/KParts/LiveConnectExtension c3e9e59 
   src/includes/KParts/MainWindow 452e115 
 
 Diff: https://git.reviewboard.kde.org/r/115098/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 115098: Adapt KParts compat-forwarding headers to new one-header-per-class policy in KParts

2014-01-19 Thread Friedrich W. H. Kossebau


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115098/
---

(Updated Jan. 19, 2014, 5:30 p.m.)


Review request for KDE Frameworks and David Faure.


Changes
---

Updated patch to not remove any of the KDE4Support-installed KPart forwarding 
headers


Repository: kde4support


Description
---

Counterpart to: https://git.reviewboard.kde.org/r/115097/

Main discussion over there, please.


Diffs (updated)
-

  src/includes/KParts/WindowArgs c3e9e59 
  src/kparts/listingextension.h PRE-CREATION 
  src/CMakeLists.txt 23b0d6d 
  src/includes/CMakeLists.txt 2b2130f 
  src/includes/KParts/BrowserExtension c3e9e59 
  src/includes/KParts/BrowserHostExtension c3e9e59 
  src/includes/KParts/Event dabdd2f 
  src/includes/KParts/GUIActivateEvent dabdd2f 
  src/includes/KParts/HtmlExtension aae280e 
  src/includes/KParts/ListingExtension 38598f9 
  src/includes/KParts/LiveConnectExtension c3e9e59 
  src/includes/KParts/OpenUrlEvent c3e9e59 
  src/includes/KParts/Part bcb6c5e 
  src/includes/KParts/PartActivateEvent dabdd2f 
  src/includes/KParts/PartBase bcb6c5e 
  src/includes/KParts/PartSelectEvent dabdd2f 
  src/includes/KParts/ReadOnlyPart bcb6c5e 
  src/includes/KParts/ReadWritePart bcb6c5e 

Diff: https://git.reviewboard.kde.org/r/115098/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 115098: Adapt KParts compat-forwarding headers to new one-header-per-class policy in KParts

2014-01-19 Thread Friedrich W. H. Kossebau


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115098/
---

(Updated Jan. 19, 2014, 9:55 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Repository: kde4support


Description
---

Counterpart to: https://git.reviewboard.kde.org/r/115097/

Main discussion over there, please.


Diffs
-

  src/includes/KParts/WindowArgs c3e9e59 
  src/kparts/listingextension.h PRE-CREATION 
  src/CMakeLists.txt 23b0d6d 
  src/includes/CMakeLists.txt 2b2130f 
  src/includes/KParts/BrowserExtension c3e9e59 
  src/includes/KParts/BrowserHostExtension c3e9e59 
  src/includes/KParts/Event dabdd2f 
  src/includes/KParts/GUIActivateEvent dabdd2f 
  src/includes/KParts/HtmlExtension aae280e 
  src/includes/KParts/ListingExtension 38598f9 
  src/includes/KParts/LiveConnectExtension c3e9e59 
  src/includes/KParts/OpenUrlEvent c3e9e59 
  src/includes/KParts/Part bcb6c5e 
  src/includes/KParts/PartActivateEvent dabdd2f 
  src/includes/KParts/PartBase bcb6c5e 
  src/includes/KParts/PartSelectEvent dabdd2f 
  src/includes/KParts/ReadOnlyPart bcb6c5e 
  src/includes/KParts/ReadWritePart bcb6c5e 

Diff: https://git.reviewboard.kde.org/r/115098/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KIO::convertSize(.,.) vs. KFormat::formatByteSize(...)

2014-01-23 Thread Friedrich W. H. Kossebau

Hi,

I see a few overlappings between methods in KFormat (KCoreAddons) and KIO 
(KIOCore), mainly this pair:

namespace KIO
{
typedef qulonglong filesize_t;
KIOCORE_EXPORT QString convertSize(KIO::filesize_t size);
}

[[Takes the binary unit dialect to use from a config file given by 
QStandardPaths::GenericDataLocation, QLatin1String(locale/) + 
QString::fromLatin1(l10n/%1/entry.desktop).arg(countryString), from the 
group KCM Locale. Returns a number with the biggest unit where the exponent 
is not 0.]]


and

class KCOREADDONS_EXPORT KFormat Q_DECL_FINAL
{
QString formatByteSize(double size,
   int precision = 1,
   KFormat::BinaryUnitDialect dialect =
   KFormat::DefaultBinaryDialect,
   KFormat::BinarySizeUnits units =
   KFormat::DefaultBinaryUnits) const;
};


Questions:

Q1) What config files can be expected from KF5 modules?
So can KIO::convertSize(...) (which is already KDE4 code) expect such config 
files to exist? Only in a Plasma workspace platform, or? How is platform 
integration done in the KDE frameworks? E.g. in Unity, GNOME Shell, Win, etc. 
I would expect that any matching config data is picked, if there is, otherwise 
a hardcoded default. http://community.kde.org/Frameworks/Policies does not 
mention that yet, but I guess that has been discussed before?


Q2) Should KIO::convertSize(...) not use KFormat::formatByteSize(...) behind 
the scenes? (At least if it is turned into a deprecated method in the future?)
KIOCore currently already depends on KCoreAddons (due to KJob). Would be 
strange if programs built on KF5 display file sizes differently, due to 
different respected settings in the both methods.


Q3) Is double as type of parameter size for KFormat::formatByteSize(...) 
really a good choice?
I would expect the type to be rather qulonglong, like it is with 
KIO::convertSize(...). I have looked at many files with Okteta, but so for not 
seen a file with a fraction byte ;)


There are a few more toString-formatting methods next to 
KIO::convertSize(...), somehow I think those might be rather part of KFormat 
API as well. But first I would like to see those 3 questions resolved.

Cheers
Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIO::convertSize(.,.) vs. KFormat::formatByteSize(...)

2014-01-25 Thread Friedrich W. H. Kossebau

Hi David, Michael, everyone,

Am Freitag, 24. Januar 2014, 09:40:00 schrieb David Faure:
 On Thursday 23 January 2014 23:43:36 Friedrich W. H. Kossebau wrote:
  Hi,
  
  I see a few overlappings between methods in KFormat (KCoreAddons) and KIO
  (KIOCore), mainly this pair:
  
  namespace KIO
  {
  typedef qulonglong filesize_t;
  KIOCORE_EXPORT QString convertSize(KIO::filesize_t size);
  }
  and
  
  class KCOREADDONS_EXPORT KFormat Q_DECL_FINAL
  {
  
  QString formatByteSize(double size,
  
 int precision = 1,
 KFormat::BinaryUnitDialect dialect =
 
 KFormat::DefaultBinaryDialect,
 
 KFormat::BinarySizeUnits units =
 
 KFormat::DefaultBinaryUnits) const;
  
  };
 
 I think it makes sense to have two methods, at two different layers.
 The KFormat one is like Qt: the caller of the method decides what they want.
 The KIO one is as we like things in KDE, very often: it takes into account
 the user's preference, for consistency across all KDE applications.
 
 The KF5/Qt5 trend is to make that happen automatically behind the scenes of
 the lowlevel (e.g. Qt) API, but that doesn't work for a method that is so
 low-level that it actually takes the settings as parameters :)

Now, KFormat::formatByteSize(...) takes as default values 
KFormat::DefaultBinaryDialect and KFormat::DefaultBinaryUnits. Both settings 
mean that something should be chosen that is default. So from an API point of 
view
KFormat::formatByteSize( byteSize )
and 
KIO::convertSize( byteSize )
should behave and look the same, right? :)
(Currently just the used defaults are/can be different)

You say consistency across all KDE applications:
As a user I would like consistency across all my apps :) I do not (want to) 
care what programming language and toolkit the developers preferred to know 
what to expect in the UI. Programs should simply adapt to the system settings.
And the system is: the environment the program is running in, either something 
fixed when creating the binary/package (Android, Sailfish, BB, Windows, OSX) 
or something less fixed (Plasma Workspace, LXDE/Razor, GNOME Shell, Unity, 
Enlightenment, XFCE).

So for systems where the default of a certain parameter is an option, I expect 
the code to read that option in, and where it is not, I expect it to be 
hardcoded to what makes sense on the system. For fixed systems that could be 
compiled in hard, for less fixed this needs some runtime switching, either by 
plugin or if-else code.

In a Plasma Workspace I expect the bytesize parameter defaults to be 
configurable, like it used to be. And any program which wants to properly 
integrate into that environment should pick these defaults up. Like I expect 
the position of the Cancel/Ok buttons to be picked up :)
Possibly Plasma Workspace might be the only one where it is configurable, but 
fine. That is one of the added-value of it :) (LXDE/Razor might be interested 
to have it as well)

Or what is the direction? Maybe I misunderstood the intention of KF5, but I 
thought it should be more nice Qt5 extension and not depend on lots of the 
typical KDE runtime, unless useful for integration in a Plasma workspace (or 
any other environment from KDE).

  Questions:
  
  Q1) What config files can be expected from KF5 modules?
  So can KIO::convertSize(...) (which is already KDE4 code) expect such
  config files to exist? Only in a Plasma workspace platform, or? How is
  platform integration done in the KDE frameworks? E.g. in Unity, GNOME
  Shell, Win, etc. I would expect that any matching config data is picked,
  if there is, otherwise a hardcoded default.
  http://community.kde.org/Frameworks/Policies does not mention that yet,
  but I guess that has been discussed before?
 Well, does a setting exist for how to format byte sizes (including the
 choice between GB and GiB) in all these frameworks? I seriously doubt
 that So it seems to me that picking this from a KConfig file for which
 we have a KCM is the only solution?

... for which we have...: well, we have it in Plasma Workspace. There we 
should use it, sure.
But we have not in Sailfish or on Android (or would you think it makes sense 
to have a tuning app for all programs which use KF5? I do not.). And I doubt 
people interested in KF5 would like their code to still reach out for all 
those config files on those platforms as well. Especially as their apps are 
additional apps, that IMHO should integrate smoothly with what is already 
there and not suddenly start to show different formattings for file sizes, 
dates etc. Or?

Now, KCoreAddons is a Functional Qt Addon in tier 1, KIO is a Solution in 
tier 3. Hm. I wonder if that means anything for platform/system integration. 
For comparison, QtCore is expected to integrate

Re: KIO::convertSize(.,.) vs. KFormat::formatByteSize(...)

2014-01-25 Thread Friedrich W. H. Kossebau

Am Samstag, 25. Januar 2014, 21:20:25 schrieb Michael Pyne:
 On Sun, January 26, 2014 00:20:02 Friedrich W. H. Kossebau wrote:
  In a Plasma Workspace I expect the bytesize parameter defaults to be
  configurable, like it used to be. And any program which wants to properly
  integrate into that environment should pick these defaults up. Like I
  expect the position of the Cancel/Ok buttons to be picked up :)
  Possibly Plasma Workspace might be the only one where it is configurable,
  but fine. That is one of the added-value of it :) (LXDE/Razor might be
  interested to have it as well)
 
 If it helps (and might also answer a quasi-question of David's), this
 setting is configurable in the Other tab of the 'language' KCM (the
 Locale button in KDE 4's System Settings).
 
 I'm not sure where that was put in KF5/PW2 yet.

Hm, that was not my point :)
I was not wondering where in the UI of a Plasma (or perhaps Razor) environment 
a certain setting can be configured.
Instead I was wondering what I if I wear the hat of a developer who considers 
using next to Qt5 also KF5 should expect in non-Plasma(/Razor) environments. 

And IMHO we (KDE hat on) should with KF5 also target/embrace those who look at 
Qt5 as the option to reach a lot of platforms in one go (even those less 
preferred by us, such is life).
And IMHO KF5 code should integrate as much as possible in other 
platforms/system. And things which can not be configured in those systems 
should be hardcoded there to sensible values.

Otherwise I fear KF5 will continue to be considered rather bloatware by so far 
Qt-only using devs because it pulls in all things needed for the rich 
configurability also in non-Plasma environments.

Cheers
Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Which package will provide the common KDE library version number ?

2012-02-18 Thread Friedrich W. H. Kossebau

Am Freitag, 17. Februar 2012, 19:48:33 schrieb Alexander Neundorf:
 Hi,
 
 right now the common version number for libraries in kdelibs/KDE is defined
 in KDE4Defaults.cmake:
 
 # define the generic version of the libraries here
 # this makes it easy to advance it when the next KDE release comes
 # Use this version number for libraries which are at version n in KDE
 # version n
 set(GENERIC_LIB_VERSION 4.8.0)
 set(GENERIC_LIB_SOVERSION 4)
 
 # Use this version number for libraries which are already at version n+1
 # in KDE version n
 set(KDE_NON_GENERIC_LIB_VERSION 5.8.0)
 set(KDE_NON_GENERIC_LIB_SOVERSION 5)
 
 
 So whichever package wants to have a common version number with the rest of
 KDE, uses this.

(rest of KDE is what?)

Which is somehow broken anyway for packages outside of kdelibs. E.g. compile a 
package from KDE SC 4.7 against kdelibs 4.8, that one gets the version number 
of kdelibs 4.8. Now compile the same package from KDE SC 4.8 against kdelibs 
4.8 as well, same version number as before.
Not sure if this does not provide the base for some problems.

IMHO each package should have its own GENERIC_LIB_* vars, for some saneness. 
Otherwise those GENERIC_LIB* vars could also be set to those of Qt or whatever 
other base lib. What reason would there be to have them versioned in the same 
way the current kdelibs is versioned?

Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 120024: Prevent some false positive critical warnings for KStandardActions


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120024/
---

Review request for KDE Frameworks.


Repository: kxmlgui


Description
---

In combination with https://git.reviewboard.kde.org/r/120025/, please read that 
one first.

This part of the patch does:
* make KActionCollection::setDefaultShortcuts() invokable per 
QMetaObject::invokeMethod, so KStandardAction::create(...) can access it
* make sure that setDefaultShortcuts is also called for KStandardActions 
created in the non-default-name addAction variant
* add a new constructor to KHelpMenu to allow passing an KActionCollection in, 
so all standardactions can be created from the beginning as items in the 
actioncollection, including setup with setDefaultShortcuts

Follow-up for KHelpMenu in KParts is https://git.reviewboard.kde.org/r/120026/


Diffs
-

  src/kactioncollection.h 5dbc3c2 
  src/kactioncollection.cpp 6c7af0f 
  src/khelpmenu.h df820f2 
  src/khelpmenu.cpp 53397cc 
  src/kxmlguifactory.cpp c4ad97b 
  src/kxmlguiwindow.cpp bd89279 

Diff: https://git.reviewboard.kde.org/r/120024/diff/


Testing
---

With this and the other patches, I can see no more of those warnings for 
standard actions, both KWrite and Okteta.
Also all unit tests still work.


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 120025: Have KStandardAction::create(...) call KActionCollection::setDefaultShortcuts()


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120025/
---

Review request for KDE Frameworks.


Repository: kconfigwidgets


Description
---

As e.g. reported in https://bugs.kde.org/show_bug.cgi?id=338222 (False 
positive critical warnings for KStandardActions) currently 
KXMLGUIFactoryPrivate::saveDefaultActionProperties complains about lots of 
actions that have been created properly via KStandardActions with a 
KActionCollection as parent. Just grep the log of your favourite XMLGUI-based 
KF5-ported program to see yourself.

I have not yet completely grasped the concept of the default shortcuts and why 
they are set only explicitely via KActionCollection::setDefaultShortcuts. But 
to me it makes some sense to have this automatically called for all 
standardactions which are created directly with a KActionCollection as parent.
I decided not to change KActionCollection::addAction because I had even less 
idea what all might be affected by that.

So this is what this patch does:
* add a call to KActionCollection::setDefaultShortcuts if there is a standard 
shortcut (via QMetaObject::invokeMethod, like done for 
KActionCollection::addAction)
* also move code which only should be done in case of a created action into 
one, same branch

Needs https://git.reviewboard.kde.org/r/120024/ to make 
KActionCollection::setDefaultShortcuts() invokable.


Diffs
-

  src/kstandardaction.cpp a18527b 

Diff: https://git.reviewboard.kde.org/r/120025/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 120026: Pass KActionCollection to KHelpMenu for KParts::MainWindow


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120026/
---

Review request for KDE Frameworks.


Repository: kparts


Description
---

See https://git.reviewboard.kde.org/r/120024/, to be committed after that one.


Diffs
-

  src/mainwindow.cpp 7e2ad9c 

Diff: https://git.reviewboard.kde.org/r/120026/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120026: Pass KActionCollection to KHelpMenu for KParts::MainWindow


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120026/
---

(Updated Aug. 31, 2014, 4:37 nachm.)


Review request for KDE Frameworks.


Repository: kparts


Description
---

See https://git.reviewboard.kde.org/r/120024/, to be committed after that one.


Diffs
-

  src/mainwindow.cpp 7e2ad9c 

Diff: https://git.reviewboard.kde.org/r/120026/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120025: Have KStandardAction::create(...) call KActionCollection::setDefaultShortcuts()


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120025/
---

(Updated Aug. 31, 2014, 4:38 nachm.)


Review request for KDE Frameworks.


Repository: kconfigwidgets


Description
---

As e.g. reported in https://bugs.kde.org/show_bug.cgi?id=338222 (False 
positive critical warnings for KStandardActions) currently 
KXMLGUIFactoryPrivate::saveDefaultActionProperties complains about lots of 
actions that have been created properly via KStandardActions with a 
KActionCollection as parent. Just grep the log of your favourite XMLGUI-based 
KF5-ported program to see yourself.

I have not yet completely grasped the concept of the default shortcuts and why 
they are set only explicitely via KActionCollection::setDefaultShortcuts. But 
to me it makes some sense to have this automatically called for all 
standardactions which are created directly with a KActionCollection as parent.
I decided not to change KActionCollection::addAction because I had even less 
idea what all might be affected by that.

So this is what this patch does:
* add a call to KActionCollection::setDefaultShortcuts if there is a standard 
shortcut (via QMetaObject::invokeMethod, like done for 
KActionCollection::addAction)
* also move code which only should be done in case of a created action into 
one, same branch

Needs https://git.reviewboard.kde.org/r/120024/ to make 
KActionCollection::setDefaultShortcuts() invokable.


Diffs
-

  src/kstandardaction.cpp a18527b 

Diff: https://git.reviewboard.kde.org/r/120025/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120025: Have KStandardAction::create(...) call KActionCollection::setDefaultShortcuts()


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120025/
---

(Updated Aug. 31, 2014, 4:40 nachm.)


Review request for KDE Frameworks.


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


Repository: kconfigwidgets


Description
---

As e.g. reported in https://bugs.kde.org/show_bug.cgi?id=338222 (False 
positive critical warnings for KStandardActions) currently 
KXMLGUIFactoryPrivate::saveDefaultActionProperties complains about lots of 
actions that have been created properly via KStandardActions with a 
KActionCollection as parent. Just grep the log of your favourite XMLGUI-based 
KF5-ported program to see yourself.

I have not yet completely grasped the concept of the default shortcuts and why 
they are set only explicitely via KActionCollection::setDefaultShortcuts. But 
to me it makes some sense to have this automatically called for all 
standardactions which are created directly with a KActionCollection as parent.
I decided not to change KActionCollection::addAction because I had even less 
idea what all might be affected by that.

So this is what this patch does:
* add a call to KActionCollection::setDefaultShortcuts if there is a standard 
shortcut (via QMetaObject::invokeMethod, like done for 
KActionCollection::addAction)
* also move code which only should be done in case of a created action into 
one, same branch

Needs https://git.reviewboard.kde.org/r/120024/ to make 
KActionCollection::setDefaultShortcuts() invokable.


Diffs
-

  src/kstandardaction.cpp a18527b 

Diff: https://git.reviewboard.kde.org/r/120025/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120025: Have KStandardAction::create(...) call KActionCollection::setDefaultShortcuts()

2014-09-05 Thread Friedrich W. H. Kossebau



 On Sept. 1, 2014, 7:55 vorm., David Faure wrote:
  You wrote: I have not yet completely grasped the concept of the default 
  shortcuts and why they are set only explicitely via 
  KActionCollection::setDefaultShortcuts.
  
  I think the concept is simple. QAction only knows the current shortcuts, 
  those that will trigger the action. Now imagine that the user configures 
  the shortcut for the quit action (default Ctrl+Q) to use something else 
  instead (Ctrl+E for exit, whatever). QAction will then only know about 
  Ctrl+E, the actual active shortcut. But the shortcut configuration dialog 
  needs to know that the default shortcut was Ctrl+Q, so that we can offer 
  revert to default, for instance (and to show that the shortcut was 
  manually modified).
  This information API is in KActionCollection because, well, there's no 
  KAction anymore, and it stores the default shortcut into the QAction as a 
  dynamic property.
  
  Well, this means another solution could be to just set the dynamic property 
  in KStandardAction, without going through KActionCollection via 
  invokeMethod. That would probably more robust,
  including the case of creating an action without a collection as parent, 
  and then putting it into a collection later on.
  
  Good thing I wrote the explanation, it made me realize that there is a 
  better solution :-)

Ah, so KActionCollection::setDefaultShortcuts is from KAction, and might not 
just have found a better place? I see. When looking at the implementation I was 
puzzled why it is not a static method, given that it does not use the 
KActionCollection object itself for anything. So not really done by original 
design.
Putting the property already directly in KStandardAction seems an option as 
well. Creates an informal dependency, as the property id used has to be kept in 
sync, but might be okay.
I am not sure though if the property should be set also if there is no 
KActionCollection given as parent, because that would mean that people using 
KConfigWidgets, but not KXMLGUI, still will get a payload of that extra 
property on every standard action they create. Instinctively I would say No to 
that, but perhaps others are more pragmatic and do not do byte-counting?


- Friedrich W. H.


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120025/#review65624
---


On Aug. 31, 2014, 4:40 nachm., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120025/
 ---
 
 (Updated Aug. 31, 2014, 4:40 nachm.)
 
 
 Review request for KDE Frameworks.
 
 
 Bugs: 338222
 https://bugs.kde.org/show_bug.cgi?id=338222
 
 
 Repository: kconfigwidgets
 
 
 Description
 ---
 
 As e.g. reported in https://bugs.kde.org/show_bug.cgi?id=338222 (False 
 positive critical warnings for KStandardActions) currently 
 KXMLGUIFactoryPrivate::saveDefaultActionProperties complains about lots of 
 actions that have been created properly via KStandardActions with a 
 KActionCollection as parent. Just grep the log of your favourite XMLGUI-based 
 KF5-ported program to see yourself.
 
 I have not yet completely grasped the concept of the default shortcuts and 
 why they are set only explicitely via KActionCollection::setDefaultShortcuts. 
 But to me it makes some sense to have this automatically called for all 
 standardactions which are created directly with a KActionCollection as parent.
 I decided not to change KActionCollection::addAction because I had even less 
 idea what all might be affected by that.
 
 So this is what this patch does:
 * add a call to KActionCollection::setDefaultShortcuts if there is a standard 
 shortcut (via QMetaObject::invokeMethod, like done for 
 KActionCollection::addAction)
 * also move code which only should be done in case of a created action into 
 one, same branch
 
 Needs https://git.reviewboard.kde.org/r/120024/ to make 
 KActionCollection::setDefaultShortcuts() invokable.
 
 
 Diffs
 -
 
   src/kstandardaction.cpp a18527b 
 
 Diff: https://git.reviewboard.kde.org/r/120025/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120025: Have KStandardAction::create(...) call KActionCollection::setDefaultShortcuts()

2014-09-07 Thread Friedrich W. H. Kossebau


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120025/
---

(Updated Sept. 7, 2014, 6 nachm.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


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


Repository: kconfigwidgets


Description
---

As e.g. reported in https://bugs.kde.org/show_bug.cgi?id=338222 (False 
positive critical warnings for KStandardActions) currently 
KXMLGUIFactoryPrivate::saveDefaultActionProperties complains about lots of 
actions that have been created properly via KStandardActions with a 
KActionCollection as parent. Just grep the log of your favourite XMLGUI-based 
KF5-ported program to see yourself.

I have not yet completely grasped the concept of the default shortcuts and why 
they are set only explicitely via KActionCollection::setDefaultShortcuts. But 
to me it makes some sense to have this automatically called for all 
standardactions which are created directly with a KActionCollection as parent.
I decided not to change KActionCollection::addAction because I had even less 
idea what all might be affected by that.

So this is what this patch does:
* add a call to KActionCollection::setDefaultShortcuts if there is a standard 
shortcut (via QMetaObject::invokeMethod, like done for 
KActionCollection::addAction)
* also move code which only should be done in case of a created action into 
one, same branch

Needs https://git.reviewboard.kde.org/r/120024/ to make 
KActionCollection::setDefaultShortcuts() invokable.


Diffs
-

  src/kstandardaction.cpp a18527b 

Diff: https://git.reviewboard.kde.org/r/120025/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120024: Prevent some false positive critical warnings for KStandardActions

2014-09-07 Thread Friedrich W. H. Kossebau


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120024/
---

(Updated Sept. 7, 2014, 6:03 nachm.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Repository: kxmlgui


Description
---

In combination with https://git.reviewboard.kde.org/r/120025/, please read that 
one first.

This part of the patch does:
* make KActionCollection::setDefaultShortcuts() invokable per 
QMetaObject::invokeMethod, so KStandardAction::create(...) can access it
* make sure that setDefaultShortcuts is also called for KStandardActions 
created in the non-default-name addAction variant
* add a new constructor to KHelpMenu to allow passing an KActionCollection in, 
so all standardactions can be created from the beginning as items in the 
actioncollection, including setup with setDefaultShortcuts

Follow-up for KHelpMenu in KParts is https://git.reviewboard.kde.org/r/120026/


Diffs
-

  src/kactioncollection.h 5dbc3c2 
  src/kactioncollection.cpp 6c7af0f 
  src/khelpmenu.h df820f2 
  src/khelpmenu.cpp 53397cc 
  src/kxmlguifactory.cpp c4ad97b 
  src/kxmlguiwindow.cpp bd89279 

Diff: https://git.reviewboard.kde.org/r/120024/diff/


Testing
---

With this and the other patches, I can see no more of those warnings for 
standard actions, both KWrite and Okteta.
Also all unit tests still work.


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120026: Pass KActionCollection to KHelpMenu for KParts::MainWindow

2014-09-07 Thread Friedrich W. H. Kossebau


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120026/
---

(Updated Sept. 7, 2014, 6:03 nachm.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Repository: kparts


Description
---

See https://git.reviewboard.kde.org/r/120024/, to be committed after that one.


Diffs
-

  src/mainwindow.cpp 7e2ad9c 

Diff: https://git.reviewboard.kde.org/r/120026/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Detailed dependencies of frameworks on external resources like icons

2014-09-17 Thread Friedrich W. H. Kossebau

Hi,

are there any plans to document which external resources like icons are 
exactly needed by the individual framework modules?

Problem:
Imagine a developer planning to use KDE frameworks to write a program for a 
platform with no proper package system, so all deps of the program need to be 
co-packaged with the program.
How can that developer know which icons (and in which sizes) need to be 
packaged as well, given the frameworks used by the program?

Simply saying all of oxygen icons might not be the best, if you look e.g. at 
the sizes of openSUSE's Tubleweed packages of the Oxygen icons:
 oxygen-icon-theme-4.13.3-4.1.noarch.rpm  PNG, no 128x128 9.7M
 oxygen-icon-theme-large-4.13.3-4.1.noarch.rpmPNG, all 128x128   19M
 oxygen-icon-theme-scalable-4.13.3-4.1.noarch.rpm SVG   234M
With high resolutions getting fancy, this will blow up the size of the package 
to rather non-acceptable sizes.


Partial solution in Calligra:
Two years ago, to fight the number of unknown icons appearing in the UI and 
reducing duplicated icons in the Calligra repo itself, some macros have been 
introduced in Calligra, to tag all icon name ids being used in the program, so 
automatic extraction and processing is possible, using gettext:
https://projects.kde.org/projects/calligra/repository/revisions/master/entry/KoIcon.h

Using these macros needs discipline, because nothing (as in: compiler) 
enforces the use of them. But so far it worked out, unkwown icons are seldomly 
seen now, and lots of icons duplicated from the Oxygen iconset could be 
removed. The script for checking duplicates, unused or unknown icons is 
https://projects.kde.org/projects/calligra/repository/revisions/master/entry/devtools/iconcheck/iconcheck.py

Just, this did not help with finding those icons used directly from kdelibs. 
So the single installer Windows packages created for Krita have been larger 
then needed, due to playing safe and shipping more or less also the complete 
Oxygen icons.

For mobile platforms with limited resources in bandwith and storage size not 
really acceptable.


Has this been discussed before? What would you propose how to deal with this 
problem? Would such macros make sense for frameworks for the described 
problem? How to collect the info which sizes of the icons might be only 
needed?

While talking about that at Akademy, Patrick von Reth had the good idea that 
this macro could also be used to alternatively resolve to qrc:/ resource 
links, to automatically support program variants where icons are stored 
internally, without a need to rewrite any reference. So someone packaging an 
app X could compile the used and co-packaged frameworks with some proper flag 
to tune the macro resolution to what would be needed.

Cheers
Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 121265: Make modified flag work for KMainWindow::setCaption(QString, bool)

2014-11-26 Thread Friedrich W. H. Kossebau

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121265/
---

Review request for KDE Frameworks.

Repository: kxmlgui

Description
---

The API dox of KMainWindow::setCaption(const QString caption, bool modified)
claims that the flag modified specifies whether the document is modified. This
displays an additional sign in the title bar, usually *.
See
http://api.kde.org/frameworks-api/frameworks5-apidocs/kxmlgui/html/classKMainWindow.html#aa78364d5eeb1c1f5bd333c733378741d

Currently that is not true. Instead a warning is shown on the console:
QWidgetPrivate::setWindowModified_helper: QWidget::setWindowModified: The
window title does not contain a '[*]' placeholder

When 'KDialog::setCaption(QString, bool)' was moved to
'KMainWindow::setCaption(QString, bool)' for kf5, it was dumped that the old
code also called ' makeStandardCaption(...)' which would add a custom
[modified] string if the 'modified' flag was set. See
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/kdialog_8cpp_source.html#l00475

Now KMainWindow uses the 'windowModified' property of 'QWidget', and if doing
so, the windowtitle needs a placeholder where to put the modified marker, by
the form of [*]. See
https://qt-project.org/doc/qt-5/qwidget.html#windowTitle-prop

This patch proposes to comply to the API and to add that placeholder, so the
method behaves as expected. It does not use [modified] flag like the kde4libs
variant of the code did, but by using the Qt placeholder perhaps can even
integrate better into the platform (not sure if there is a hook yet).

Diffs
-

src/kmainwindow.cpp 9562318

Diff: https://git.reviewboard.kde.org/r/121265/diff/

Testing
---

Modified is now properly marked to Off or On in the window title, when
'KMainWindow::setCaption(QString,bool)' is used. Tested with Okteta.

Thanks,

Friedrich W. H. Kossebau

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: proposal: remove KTextEditor interface from kdelibs repository

Mardi, le 1 février 2011, à 16:43, Maksim Orlovich a écrit:
  erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no
  go then ... hm.. looking at it, only khtml has a build-time dependency
  on it. if
  the texteditor part isn't available (or the source of the crash even? :)
  what
  does the debugger do at that point?
 
 Pop up an error message and abort execution, as it expects it to be
 part of kdelibs.
 Which is coincidentally very similar to what KTextEditor tutorials
 suggest --- see
 http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example
 (except it needs katepart in specific)

Uh, that is old-fashioned. Should instead ask the user whether she wants to 
install the proper text editor module. Isn't there some simple standard api 
for that these days?

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: proposal: remove KTextEditor interface from kdelibs repository

Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit:
 On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
  Uh, that is old-fashioned. Should instead ask the user whether she wants
  to install the proper text editor module. Isn't there some simple
  standard api for that these days?
 
 A simple standard api for what? installations of scripts and wallpapers
 and stuff, sure. there is the ghns things.
 
 For isntallation of compiled stuff, no.

Not something related to packagekit or similar? Eh, IMHO there should be 
something like that if there isn't. With OBS and Co. compiled stuff is not 
that much different, you just get a variant tailored to your (hardware) 
profil. Can someone please empty my TODO list? :)

 And I'm not sure there should be
 such a thing.

Hm. You don't agree that a user experience like
Sorry, missing X to do Y. Would you like to get X now for that?
is better than one à la
Na, no way to do Y.?

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)

Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit:
 On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
  And I'm not sure there should be
  such a thing.
  
  Hm. You don't agree that a user experience like
  
  Sorry, missing X to do Y. Would you like to get X now for that?
  
  is better than one à la
  
  Na, no way to do Y.?
 
 Yes. since we can't assume the user has the right to install to the
 system directory,

We can't assume for all, but in many installations the user does. Like the 
ususal private computer.
For administrated systems, there could be a substitute which instead of 
allowing to install rather aids the user to file a request to the admin, for 
convenience and getting things done.

 and we shouldn't set up a complete development
 environment for him.

I was thinking of interfacing to the normal packaging system of the system. 
He, something like DrKonqi installing the debug info packages on request. So 
something like that is existing already, just needs to be generalized perhaps.

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: proposal: remove KTextEditor interface from kdelibs repository

Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit:
 On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote:
  Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit:
   On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
Uh, that is old-fashioned. Should instead ask the user whether she
wants to install the proper text editor module. Isn't there some
simple standard api for that these days?
   
   A simple standard api for what? installations of scripts and wallpapers
   and stuff, sure. there is the ghns things.
   
   For isntallation of compiled stuff, no.
  
  Not something related to packagekit or similar? Eh, IMHO there should be
  something like that if there isn't. With OBS and Co. compiled stuff is
  not that much different, you just get a variant tailored to your
  (hardware) profil. Can someone please empty my TODO list? :)
  
   And I'm not sure there should be
   such a thing.
  
  Hm. You don't agree that a user experience like
  
  Sorry, missing X to do Y. Would you like to get X now for that?
  
  is better than one à la
  
  Na, no way to do Y.?
 
 I think Lubos proposed something like this recently, i.e. at some point
 last year here on this list.

Others have done now and then as well, e.g., ahem, me ;) here a few years ago:
http://markmail.org/message/xo2b4zw2ee6si6g2

Oh, how cheap talk is :P

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: Installing specific packages on demand

Mardi, le 1 février 2011, à 20:10, Sune Vuorela a écrit:
 On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
  We can't assume for all, but in many installations the user does. Like
  the ususal private computer.
  For administrated systems, there could be a substitute which instead of
  allowing to install rather aids the user to file a request to the admin,
  for convenience and getting things done.
  
  and we shouldn't set up a complete development
  environment for him.
  
  I was thinking of interfacing to the normal packaging system of the
  system. He, something like DrKonqi installing the debug info packages on
  request. So something like that is existing already, just needs to be
  generalized perhaps.
 
 Basically, a piece of software than have three relations:
 1) Required things
 2) Optional things that should be availably by default
 3) optional things that doesn't need to be available by default
 
 Packagers should assure that 1) is around. Packagers should try hard to
 make 2) available for all not uncommon installations.
 
 if 1) is missing, file bugs at the distribution.
 if 2) is missing, file bugs at the distribution or alternatively tell
 the user you broke your system, you get to keep the pieces.
 
 And then there is the handling of 3).
 
 Well.. let's not make it a bigger issue than it actually is.

Ah, Sune, guess we were missing each other :) I was talking of currently not 
installed optional things. And not speaking of optional things not existing as 
packages.

E.g. imagine someone installing some program over an expensive/slow connection 
(think mobile). She just installs the required things, to keep the needed 
bandwith low. Then hits a feature which is more useful with some optional 
thing X. Ideally the feature's code would be able to offer the action Trigger 
install of optional thing X to pimp doing Y.

Does this help to understand what I am looking forward to?

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: proposal: remove KTextEditor interface from kdelibs repository