Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

>> Boudewijn Rempt  hat am 23. Oktober 2015 um 19:46 
>> geschrieben:
>> For Krita, we decided ages ago to simply open a browser on the userbase
>> manual of Krita. Yes, it is conceivable that there are people who use
>> Krita without internet access who still need help, it's just not very
>> likely. About one complaint, maybe two in the past couple of years.
> umbrello installer also uses a khelpcenter online replacement to access 
> umbrello
> documentation from the internet instead of a local installation (see
> https://build.opensuse.org/package/show?project=windows%3Amingw%3Awin32=mingw32-khelpcenter-online)
> Currently it is limited to umbrello, but could be easily extended. klauncher
> and dbus is required to launch it from the help menu.
> Ralf

I would tend to just http://doc.qt.io/qt-5/qdesktopservices.html with the url 
to the offline copy or online page.

No dbus nor klauncher nor extra bundled application needed.
Perhaps that can be even done by magic in the frameworks ;=)

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Ralf Habacker]

Am 26.10.2015 um 10:33 schrieb Christoph Cullmann:
> Hi,
>
>>> Boudewijn Rempt  hat am 23. Oktober 2015 um 19:46 
>>> geschrieben:
>>> For Krita, we decided ages ago to simply open a browser on the userbase
>>> manual of Krita. Yes, it is conceivable that there are people who use
>>> Krita without internet access who still need help, it's just not very
>>> likely. About one complaint, maybe two in the past couple of years.
>> umbrello installer also uses a khelpcenter online replacement to access 
>> umbrello
>> documentation from the internet instead of a local installation (see
>> https://build.opensuse.org/package/show?project=windows%3Amingw%3Awin32=mingw32-khelpcenter-online)
>> Currently it is limited to umbrello, but could be easily extended. klauncher
>> and dbus is required to launch it from the help menu.
>> Ralf
> I would tend to just http://doc.qt.io/qt-5/qdesktopservices.html with the url 
> to the offline copy or online page.
>
> No dbus nor klauncher nor extra bundled application needed.
> Perhaps that can be even done by magic in the frameworks ;=)
>From what I see from the frameworks source do KXMLGui based applications
call QDesktopServices:openURL already, see
*https://projects.kde.org/projects/frameworks/kxmlgui/repository/revisions/master/entry/src/khelpmenu.cpp#L249*.

In KGuiAddons there is a global instance of class UrlHandler, which setup 
setURLHandler() in 
https://projects.kde.org/projects/frameworks/kguiaddons/repository/revisions/master/entry/src/util/urlhandler.cpp.
Selecting "show manual" in KXMLGui based application will therefore be handled 
by this UrlHandler instance. In case the khelpcenter executable has not been 
found QDesktopServices::openUrl(u) is called again. Candidate for a recursive 
loop ?
 
BTW: You mentioned the url  
https://docs.kde.org/stable5/en/applications/kate/index.html in an earlier 
email to access online help. khelpcenter determine the currently selected 
language by itself and loads the language related doc. This need to be fixed in 
class UrlHandler too.


Ralf 

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

Re: Question about goal of Windows/Mac frameworks

[Luigi Toscano]

On Monday 26 of October 2015 11:50:10 Ralf Habacker wrote:

> 
> BTW: You mentioned the url 
> https://docs.kde.org/stable5/en/applications/kate/index.html in an earlier
> email to access online help. khelpcenter determine the currently selected
> language by itself and loads the language related doc. This need to be
> fixed in class UrlHandler too.

Side note: please never use that URL directly. Use this:

https://docs.kde.org/index.php?application=kate=en=stable5

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

Re: Question about goal of Windows/Mac frameworks

[Aleix Pol]

On Mon, Oct 26, 2015 at 10:33 AM, Christoph Cullmann
 wrote:
> Hi,
>
>>> Boudewijn Rempt  hat am 23. Oktober 2015 um 19:46 
>>> geschrieben:
>>> For Krita, we decided ages ago to simply open a browser on the userbase
>>> manual of Krita. Yes, it is conceivable that there are people who use
>>> Krita without internet access who still need help, it's just not very
>>> likely. About one complaint, maybe two in the past couple of years.
>> umbrello installer also uses a khelpcenter online replacement to access 
>> umbrello
>> documentation from the internet instead of a local installation (see
>> https://build.opensuse.org/package/show?project=windows%3Amingw%3Awin32=mingw32-khelpcenter-online)
>> Currently it is limited to umbrello, but could be easily extended. klauncher
>> and dbus is required to launch it from the help menu.
>> Ralf
>
> I would tend to just http://doc.qt.io/qt-5/qdesktopservices.html with the url 
> to the offline copy or online page.
>
> No dbus nor klauncher nor extra bundled application needed.
> Perhaps that can be even done by magic in the frameworks ;=)

I made a fast patch that implements this, maybe it will work.
Feedback welcome: https://git.reviewboard.kde.org/r/125815/

I'm feeling a bit unsecure because I'm not really sure how the url
works on docs.kde.org side of things, but looks promising.

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

Re: Question about goal of Windows/Mac frameworks

[Ralf Habacker]

> Boudewijn Rempt  hat am 23. Oktober 2015 um 19:46
> geschrieben:
 
> For Krita, we decided ages ago to simply open a browser on the userbase
> manual of Krita. Yes, it is conceivable that there are people who use
> Krita without internet access who still need help, it's just not very
> likely. About one complaint, maybe two in the past couple of years.
 
umbrello installer also uses a khelpcenter online replacement to access umbrello
documentation from the internet instead of a local installation (see
https://build.opensuse.org/package/show?project=windows%3Amingw%3Awin32=mingw32-khelpcenter-online)
Currently it is limited to umbrello, but could be easily extended. klauncher and
dbus is required to launch it from the help menu.
 
Ralf
 ___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Kevin Ottens]

Hello,

On Wednesday 21 October 2015 22:22:54 Christoph Cullmann wrote:
> > On Wednesday 21 October 2015 21:06:02 Christoph Cullmann wrote:
> > My concern there is more the fact that this kind of "short term" or
> > "temporary" solutions tend to become permanent. As long as it is causing
> > pain you can hope someone will look at it and try to fix it... and
> > indeed, see what you achieved! ;-)
> > But if you put in place something short term lifting the immediate pain,
> > people will learn to live with it and it'll stay. I hope we'll avoid that.
> 
> At the moment my biggest concern is, that we stay in the status quo:

That's why I mention pain. If there's no pain involved then yes, slipping in 
the status quo is involved. If there's some pain, at one point someone (like 
you) gets annoyed and start to shake things.
 
> Frameworks as in our git master branch are more or less "not usable" on non
> linux/xdg conform systems (beside pure functional tier1 or so) and all
> people that do use them on other systems hack happy away using patches for
> Qt/frameworks/applications floating around on github/macports/mingw/ or
> just fork and shrink the frameworks locally.

Right, *that* is a problem. A few years back it wouldn't have happened though. 
In some way we lost the culture of every team having people not shying away 
from touching kdelibs (at the time) in case of needs, now most teams consider 
it as a black box. I wish we'd go back to the old ways regarding people 
involvement in frameworks (and you give me hope there) because otherwise 
middle to longer term we're on the right path for a tragedy of the commons 
(kdelibs now KF being clearly one, especially for our community).

> Given we want to broaden our scope away from the "pure Linux/X11(Wayland)
> Desktop" country, that makes me a bit sad. But I see progress in the right
> direction and interest by people to help out.

Yes, and I'm delighted about that!

Cheers.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Kevin Ottens]

Hello,

On Friday 23 October 2015 16:35:36 Luigi Toscano wrote:
> On Wednesday 21 of October 2015 20:09:33 Kevin Ottens wrote:
> > And then, three areas of efforts which we are missing right now in
> > Frameworks: - systematically try to reduce the tier and type of our
> > frameworks (the maturity direction I was talking about);
> 
> Do you mean that a Framework is mature only if it's tier1?

No, I might have been unclear indeed. The point I'm trying to make is that it 
gives a *direction* toward a framework improvement. A framework is mature when 
it reached it's optimum place which is generally closer to the bottom right 
(in the matrix I posted the last time) than from where it started.

That kind of thinking and investigation per framework takes time and as such 
we tend to not do it. For sure we didn't do it systematically, and I think 
ideally that would be needed.

> Is KIO non mature (and it won't probably ever be)?

Difficult to answer without digging deeper into its current state since I 
didn't look into it for a while now, but I would say it's close to be but not 
yet.
I'm saying this mostly because I assume KIO could become Tier 2, could hardly 
be something else than of type Solution though, and it's not there yet. If my 
assumption is wrong then it's already at the right place, end of story.

> I see some functions being so complex that in order to lower the tier for a
> framework one of the two should happen:
> 1) remove functionalities

Yes, there's remove and remove though. :-)

We always assumed everything is used by everyone or required by everyone, 
might not be true and so could be removed (it's the most difficult to find).
It could be some convenience API that allows our applications to spare two 
lines of code... is it really worth it to carry extra dependencies and 
complexity in the frameworks for that? Perhaps not.
It could be some automated behavior which makes sense only if the application 
links to a combination of frameworks but not if the application links to a 
single framework. In such case probably one of the soft dependencies tricks we 
used in the past could apply. It's a Schrodinger features. :-) 

It's all removal to some extent, but it's far from black and white.

> 2) put code in Qt.

Or in a framework of a lower tier. For instance something which is Tier 3 and 
which could be improved to become Tier 2 might require some code be put in a 
Tier 1 framework.

> Even 2) would be quite hard, and I wonder what would happen if all the
> relevant code would end up in Qt

Well, we'd have put quite some work into it then. :-)

It's doable, we did it in the past, there's probably more we could do, but it 
clearly requires getting out of our comfort zone. Can't have it all I guess. 
:-)

> (yeah, almost "kdelibs merged into Qt"! and maybe someone on some
> forum/known website would start screaming about a bloated Qt without
> thinking about the situation, but I'm digressing).

We don't need to get even close to a kdelibs merged into Qt. Quite a lot of 
things wouldn't apply to something like Qt. But clearly we have some internal 
or lower level mechanisms used at plenty of places, those would make sense in 
Qt.

> My take: it is simply not possible (not before maybe Qt 7) to reduce the
> level of some frameworks, without them being "immature".

For the record, this kind of thinking is not really to my taste because it 
opens the door to build up excuses for our own behavior: "oh well, it's not 
possible, why bother anyway..."

For sure, we have way more opportunities to improve ourselves and our 
frameworks first before even starting to perceive limits really out of our 
control.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Jaroslaw Staniek]

On 23 October 2015 at 16:18, Luigi Toscano  wrote:
> On Friday 23 of October 2015 10:31:36 Christoph Cullmann wrote:
>> Hi,
>>
>> > Am 21.10.2015 um 12:41 schrieb Christoph Cullmann:
>> >> The last time I build umbrello with kf5 (version 5.11) dbus was required
>> >> to run khelpcenter and open/save file dialogs and for remote control.
>> >> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/wind
>> >> ows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-installer
>> >> -2.18.99-4.1.noarch.rpm (you may open this rpm with ark of 7zip file
>> >> manager to get the installer) open/save stuff is fixed in KF5 master
>> >> But yes, khelpcenter (if it is shipped) might need fixing
>> >
>> > khelpcenter is launched by klauncher5 through dbus
>>
>> I guess for Windows/Mac one would need to generate the help as plain HTML
>> anyway, as you don't want to ship KHelpCenter with your application nor
>> want to require it to be there (given it uses KHTML and more stuff ;=)
>
> How are you going to generate plain HTML if the proper macros should be in the
> (disabled) KDocTools anyway (because the docbooks - and in future other
> formats - could depend on common files?
>
> The funny thing about this story from my point of view is that, in order to
> show that we support other platform, we are going to show that which is the
> proper platform which does not force developers to cut down functionalities.
>
> Side note: LibreOffice ships its help viewer and I don't think anyone
> complained so far.

I wouldn't use something as strong as "anyone".
Technical decisions come from the StarOffice era when the target was
Windows 95 without basic facilities and with limited help viewers. The
same reason why some internal legacy UI framework was and still is
used. There was even a replacement for entire desktop.

Let's look about part of the whole frameworks goal: providing help
facilities for use in apps. There's a bit of my POV.

And still even this win95-like HTML4-based infra for help feels like
much more *compact* (I worked with the translation team for OpenOffice
back then) than dbus+docbook+init daemon+browser engine.
I simply wouldn't use all that on platforms where it's easy to spot
antivirus tools blocking such a bloat. That's one reason. Another is
that I prefer to spend time on app features and fixes, not on making
the 3rd-party OS, a FOSS-like. Thirdly, after the docbook (or its wiki
converter) approach rather failed in practice because of no tooling
friendly to actual people with domain knowledge (so no contributions
for ages for my apps) I am investigating asciidoc and similar
solutions. Or maybe Free documentation failed for that matter, what
brings the same point back: commercial work on docs has to be
resource-optimized, KISS like.

Qt apps (for non-Linux) I've been working on, pressed on CDs back then
have been running Qt Assistant bundled with the whole installation. So
that was "own" help solution based on a customized template. The point
is, with a self-contained component, user can run any number of apps,
each employing own Assistant and there wouldn't be a flood of kdeinit
or dbus sessions around. I remember that especially casual users, for
a reason, notice a process bloat of a ported app. It's like current
cars that hide everything from the user, especially everything that
could kill her/him.

And other than an exerciuse, I don't see a need for fighting for 1-1
portability of such tools that are part of the workspace infra, not
the app itself. Especially that some my apps won't use that for sure
on tablets. If I can strip-down the app for tablet, and even write a
GUI from scratch, I can do use the same for Windows and Mac desktops
as well. That's mostly the same task that scales quite well.

Now I don't know last time when I've seen any user browsing the help
other than API docs. I bet there are some but issue solving via
documentation is way worse than via googling now. Ask yourselves. So
perhaps there's even that not much to fight about. I've seen that full
MS Office 2013 installation does not come with usable manual... And I
tried to google a clear evidence that users complain about that, but I
failed.

Actually let's look as a popular ported standalone app: GTK/GNOME's
help-browser that GIMP uses on Windows is the same as on Linux but I
don't see it using dbus (but still webkitgtk is used). Moreover if
someone caring for UX reads this: KDE's app help window calls itself
KDE Help Center. Compare the complexity of KDE apps' help
http://i.imgur.com/npgewCo.png to what GIMP has:
http://i.imgur.com/kNKwrzK.png. I bet Krita devs won't like to share
the help window with the KMail help (if it's even installed on
Windows). And well, ToC (or the Home button) in that app is a ToC of
"KDE", not the ToC of app :) You're welcome.

For me a lot of that applies even to Linux.

If we want 3rd-party software use our infra like that, make it
compact, we make it trivial 

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> On Fri, 23 Oct 2015, Jaroslaw Staniek wrote:
> 
>> Actually let's look as a popular ported standalone app: GTK/GNOME's
>> help-browser that GIMP uses on Windows is the same as on Linux but I
>> don't see it using dbus (but still webkitgtk is used). Moreover if
>> someone caring for UX reads this: KDE's app help window calls itself
>> KDE Help Center. Compare the complexity of KDE apps' help
>> http://i.imgur.com/npgewCo.png to what GIMP has:
>> http://i.imgur.com/kNKwrzK.png. I bet Krita devs won't like to share
>> the help window with the KMail help (if it's even installed on
>> Windows). And well, ToC (or the Home button) in that app is a ToC of
>> "KDE", not the ToC of app :) You're welcome.
> 
> For Krita, we decided ages ago to simply open a browser on the userbase
> manual of Krita. Yes, it is conceivable that there are people who use
> Krita without internet access who still need help, it's just not very
> likely. About one complaint, maybe two in the past couple of years.
Kate actually has a good maintained manual, thanks to TC. Hollingsworth and Co 
;=)

But even there, it might be simpler to just link to:


-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Luigi Toscano]

On Friday 23 of October 2015 10:31:36 Christoph Cullmann wrote:
> Hi,
> 
> > Am 21.10.2015 um 12:41 schrieb Christoph Cullmann:
> >> The last time I build umbrello with kf5 (version 5.11) dbus was required
> >> to run khelpcenter and open/save file dialogs and for remote control.
> >> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/wind
> >> ows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-installer
> >> -2.18.99-4.1.noarch.rpm (you may open this rpm with ark of 7zip file
> >> manager to get the installer) open/save stuff is fixed in KF5 master
> >> But yes, khelpcenter (if it is shipped) might need fixing
> > 
> > khelpcenter is launched by klauncher5 through dbus
> 
> I guess for Windows/Mac one would need to generate the help as plain HTML
> anyway, as you don't want to ship KHelpCenter with your application nor
> want to require it to be there (given it uses KHTML and more stuff ;=)

How are you going to generate plain HTML if the proper macros should be in the 
(disabled) KDocTools anyway (because the docbooks - and in future other 
formats - could depend on common files?

The funny thing about this story from my point of view is that, in order to 
show that we support other platform, we are going to show that which is the 
proper platform which does not force developers to cut down functionalities.

Side note: LibreOffice ships its help viewer and I don't think anyone 
complained so far.

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

Re: Question about goal of Windows/Mac frameworks

[Luigi Toscano]

On Friday 23 of October 2015 16:32:12 Christoph Cullmann wrote:
> Hi,
> 
> > On Friday 23 of October 2015 10:31:36 Christoph Cullmann wrote:
> >> Hi,
> >> 
> >> > Am 21.10.2015 um 12:41 schrieb Christoph Cullmann:
> >> >> The last time I build umbrello with kf5 (version 5.11) dbus was
> >> >> required
> >> >> to run khelpcenter and open/save file dialogs and for remote control.
> >> >> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/w
> >> >> ind
> >> >> ows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-instal
> >> >> ler
> >> >> -2.18.99-4.1.noarch.rpm (you may open this rpm with ark of 7zip file
> >> >> manager to get the installer) open/save stuff is fixed in KF5 master
> >> >> But yes, khelpcenter (if it is shipped) might need fixing
> >> > 
> >> > khelpcenter is launched by klauncher5 through dbus
> >> 
> >> I guess for Windows/Mac one would need to generate the help as plain HTML
> >> anyway, as you don't want to ship KHelpCenter with your application nor
> >> want to require it to be there (given it uses KHTML and more stuff ;=)
> > 
> > How are you going to generate plain HTML if the proper macros should be in
> > the (disabled) KDocTools anyway (because the docbooks - and in future
> > other formats - could depend on common files?
> > 
> > The funny thing about this story from my point of view is that, in order
> > to
> > show that we support other platform, we are going to show that which is
> > the
> > proper platform which does not force developers to cut down
> > functionalities.
> > 
> > Side note: LibreOffice ships its help viewer and I don't think anyone
> > complained so far.
> 
> Nobody have never said that kdoctools should be disabled for ever, and it is
> NOT even disabled at the moment, you can just build without having it
> available. And that is very reasonable, as most people don't need any of
> the documentation stuff we ship in the frameworks. An other story is the
> application documentation.

The problem is that, if you disable KDocTools because you don't want to 
generate and ship documentation with each individual framework, you are also 
disabling the generation of application documentation (which is handled again 
by KDocTools). We need a way to solve this.

Ciao
-- 
Luigi

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> On Friday 23 of October 2015 16:32:12 Christoph Cullmann wrote:
>> Hi,
>> 
>> > On Friday 23 of October 2015 10:31:36 Christoph Cullmann wrote:
>> >> Hi,
>> >> 
>> >> > Am 21.10.2015 um 12:41 schrieb Christoph Cullmann:
>> >> >> The last time I build umbrello with kf5 (version 5.11) dbus was
>> >> >> required
>> >> >> to run khelpcenter and open/save file dialogs and for remote control.
>> >> >> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/w
>> >> >> ind
>> >> >> ows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-instal
>> >> >> ler
>> >> >> -2.18.99-4.1.noarch.rpm (you may open this rpm with ark of 7zip file
>> >> >> manager to get the installer) open/save stuff is fixed in KF5 master
>> >> >> But yes, khelpcenter (if it is shipped) might need fixing
>> >> > 
>> >> > khelpcenter is launched by klauncher5 through dbus
>> >> 
>> >> I guess for Windows/Mac one would need to generate the help as plain HTML
>> >> anyway, as you don't want to ship KHelpCenter with your application nor
>> >> want to require it to be there (given it uses KHTML and more stuff ;=)
>> > 
>> > How are you going to generate plain HTML if the proper macros should be in
>> > the (disabled) KDocTools anyway (because the docbooks - and in future
>> > other formats - could depend on common files?
>> > 
>> > The funny thing about this story from my point of view is that, in order
>> > to
>> > show that we support other platform, we are going to show that which is
>> > the
>> > proper platform which does not force developers to cut down
>> > functionalities.
>> > 
>> > Side note: LibreOffice ships its help viewer and I don't think anyone
>> > complained so far.
>> 
>> Nobody have never said that kdoctools should be disabled for ever, and it is
>> NOT even disabled at the moment, you can just build without having it
>> available. And that is very reasonable, as most people don't need any of
>> the documentation stuff we ship in the frameworks. An other story is the
>> application documentation.
> 
> The problem is that, if you disable KDocTools because you don't want to
> generate and ship documentation with each individual framework, you are also
> disabling the generation of application documentation (which is handled again
> by KDocTools). We need a way to solve this.
it is not disabled. It is just possible to build without it.
If doctools will work fine, if build, is an other question.

Really, all current patches to frameworks to get them better working on win/mac
did disable exactly nothing. They only enabled to use stuff without all
dependencies around or survive things like "no-dbus session bus available".

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> On Friday 23 of October 2015 10:31:36 Christoph Cullmann wrote:
>> Hi,
>> 
>> > Am 21.10.2015 um 12:41 schrieb Christoph Cullmann:
>> >> The last time I build umbrello with kf5 (version 5.11) dbus was required
>> >> to run khelpcenter and open/save file dialogs and for remote control.
>> >> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/wind
>> >> ows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-installer
>> >> -2.18.99-4.1.noarch.rpm (you may open this rpm with ark of 7zip file
>> >> manager to get the installer) open/save stuff is fixed in KF5 master
>> >> But yes, khelpcenter (if it is shipped) might need fixing
>> > 
>> > khelpcenter is launched by klauncher5 through dbus
>> 
>> I guess for Windows/Mac one would need to generate the help as plain HTML
>> anyway, as you don't want to ship KHelpCenter with your application nor
>> want to require it to be there (given it uses KHTML and more stuff ;=)
> 
> How are you going to generate plain HTML if the proper macros should be in the
> (disabled) KDocTools anyway (because the docbooks - and in future other
> formats - could depend on common files?
> 
> The funny thing about this story from my point of view is that, in order to
> show that we support other platform, we are going to show that which is the
> proper platform which does not force developers to cut down functionalities.
> 
> Side note: LibreOffice ships its help viewer and I don't think anyone
> complained so far.
Nobody have never said that kdoctools should be disabled for ever, and it is 
NOT even disabled at
the moment, you can just build without having it available. And that is very 
reasonable,
as most people don't need any of the documentation stuff we ship in the 
frameworks.
An other story is the application documentation.

And yes, this will all take a lot more time, to have at least kind of feature 
parity on Windows
and Mac.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Luigi Toscano]

On Wednesday 21 of October 2015 20:09:33 Kevin Ottens wrote:
> 
> And then, three areas of efforts which we are missing right now in
> Frameworks: - systematically try to reduce the tier and type of our
> frameworks (the maturity direction I was talking about);

Do you mean that a Framework is mature only if it's tier1? Is KIO non mature 
(and it won't probably ever be)?
I see some functions being so complex that in order to lower the tier for a 
framework one of the two should happen:
1) remove functionalities
2) put code in Qt.

Even 2) would be quite hard, and I wonder what would happen if all the 
relevant code would end up in Qt (yeah, almost "kdelibs merged into Qt"! 
and maybe someone on some forum/known website would start screaming about a 
bloated Qt without thinking about the situation, but I'm digressing).

My take: it is simply not possible (not before maybe Qt 7) to reduce the level 
of some frameworks, without them being "immature".

Ciao
-- 
Luigi

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Am 21.10.2015 um 12:41 schrieb Christoph Cullmann:
>>
>> The last time I build umbrello with kf5 (version 5.11) dbus was required
>> to run khelpcenter and open/save file dialogs and for remote control.
>> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/windows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-installer-2.18.99-4.1.noarch.rpm
>> (you may open this rpm with ark of 7zip file manager to get the installer)
>> open/save stuff is fixed in KF5 master
>> But yes, khelpcenter (if it is shipped) might need fixing
> khelpcenter is launched by klauncher5 through dbus
I guess for Windows/Mac one would need to generate the help as plain HTML 
anyway,
as you don't want to ship KHelpCenter with your application nor want to require 
it to
be there (given it uses KHTML and more stuff ;=)

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Am 21.10.2015 um 01:19 schrieb Aleix Pol:
>> On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:
 Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
 geschrieben:
 That works only, if the applications bundle their ui files in resources,
 too, otherwise, they just won't be found
 and the applications break, unless you patch again Qt to look in
 non-standard locations.
>>> yes, the following patch
>>> https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
>>> is a workaround to fix some of the issues.
>> That's why Christoph is saying: "unless you patch again Qt to look in
>> non-standard locations.".
> umbrello for example depends on about 50 other libraries and packages
> https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
> Not patching Qt requires to repack every single package :-(, by either
> hacking the cmake build system to use different install locations or to
> reorder the installed files after cmake installing.
> 
> Having Qt support for "standard linux path layout" for example by
> extending qt.conf to support QStandardPath (qt.conf is already required
> for KDE on Windows) shortcuts this repackaging need completly.
I at least fixed already all frameworks required by the current Kate build 
(beside that KIO slave don't work atm and I guess
I missed 1-2 files still not in resources):

kconfig
kguiaddons
ki18n
kitemviews
sonnet
kwindowsystem
kwidgetsaddons
kcompletion
kdbusaddons
karchive
kcoreaddons
kjobwidgets
kcrash
kservice
kcodecs
kauth
kconfigwidgets
kiconthemes
ktextwidgets
kglobalaccel
kxmlgui
kbookmarks
solid
kio
kparts
ktexteditor

That means they now by "default" just work, if you use the master branch.
More frameworks to go, for sure, but that is really doable ;=)

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Ralf Habacker]

Am 21.10.2015 um 01:19 schrieb Aleix Pol:
> On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:
>>> Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
>>> geschrieben:
>>> That works only, if the applications bundle their ui files in resources,
>>> too, otherwise, they just won't be found
>>> and the applications break, unless you patch again Qt to look in
>>> non-standard locations.
>> yes, the following patch
>> https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
>> is a workaround to fix some of the issues.
> That's why Christoph is saying: "unless you patch again Qt to look in
> non-standard locations.".
umbrello for example depends on about 50 other libraries and packages
https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
Not patching Qt requires to repack every single package :-(, by either
hacking the cmake build system to use different install locations or to
reorder the installed files after cmake installing.

Having Qt support for "standard linux path layout" for example by
extending qt.conf to support QStandardPath (qt.conf is already required
for KDE on Windows) shortcuts this repackaging need completly.

Ralf

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

Re: Question about goal of Windows/Mac frameworks

[Boudewijn Rempt]

On Thu, 22 Oct 2015, Christoph Cullmann wrote:


If such an approach seems reasonable, we could have some helper for this in a 
framework.
Perhaps the "breeze" framework could even just provide such an rcc and a little 
lib to
load it that can be used for people creating bundles/installers.


Yes, I think it's quite reasonable. Once put into an rcc, the theme doesn't even take a 
lot space anymore. I got so many complaints about the number of files in krita's windows

installer -- because of all the icons in the theme I bundled. This is much 
nicer.

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

Re: Question about goal of Windows/Mac frameworks

[Boudewijn Rempt]

Impressive! And cool to see another project using the cmake externals 
approach, I can copy a lot of it for Krita 3, I think. How are you 
handling icons? Bundling the breeze theme, or putting the icons in resource

files?

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

On Thu, 22 Oct 2015, Christoph Cullmann wrote:


Hi,

btw., a preliminary self contained Kate for Windows can be found here:

ftp://cullmann.io/cullmann/

Created with the CMake file from this repo by Kåre Särs

https://quickgit.kde.org/?p=scratch%2Fsars%2Fkate-windows.git=tree

Plain Qt, normal Visual Studio, can be deployed without global stuff.
(you need the Visual Studio redist package, thought, or you bundle that .dll
in the zip, too)

ZIP is only around 30MB, I think that is not that bad, no real need to spend
time on sharing stuff.

Greetings
Christoph

- Am 22. Okt 2015 um 8:39 schrieb cullmann cullm...@absint.com:


Hi,


Am 21.10.2015 um 01:19 schrieb Aleix Pol:

On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:

Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
geschrieben:
That works only, if the applications bundle their ui files in resources,
too, otherwise, they just won't be found
and the applications break, unless you patch again Qt to look in
non-standard locations.

yes, the following patch
https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
is a workaround to fix some of the issues.

That's why Christoph is saying: "unless you patch again Qt to look in
non-standard locations.".

umbrello for example depends on about 50 other libraries and packages
https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
Not patching Qt requires to repack every single package :-(, by either
hacking the cmake build system to use different install locations or to
reorder the installed files after cmake installing.

Having Qt support for "standard linux path layout" for example by
extending qt.conf to support QStandardPath (qt.conf is already required
for KDE on Windows) shortcuts this repackaging need completly.

I at least fixed already all frameworks required by the current Kate build
(beside that KIO slave don't work atm and I guess
I missed 1-2 files still not in resources):

kconfig
kguiaddons
ki18n
kitemviews
sonnet
kwindowsystem
kwidgetsaddons
kcompletion
kdbusaddons
karchive
kcoreaddons
kjobwidgets
kcrash
kservice
kcodecs
kauth
kconfigwidgets
kiconthemes
ktextwidgets
kglobalaccel
kxmlgui
kbookmarks
solid
kio
kparts
ktexteditor

That means they now by "default" just work, if you use the master branch.
More frameworks to go, for sure, but that is really doable ;=)

Greetings
Christoph

--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-windows mailing list
kde-wind...@kde.org
https://mail.kde.org/mailman/listinfo/kde-windows___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Boudewijn Rempt]

On Thu, 22 Oct 2015, Christoph Cullmann wrote:


Hi,


Impressive! And cool to see another project using the cmake externals
approach, I can copy a lot of it for Krita 3, I think. How are you
handling icons? Bundling the breeze theme, or putting the icons in resource
files?

as I was lazy, I just compiled complete breeze into a binary rcc file like done 
in mac.txt: (search for the rcc calls)

https://quickgit.kde.org/?p=kate.git=blob=275a28d36b132f0f5d3963ae40b451d264bae3a5=1486c0e69df54e955e25223ff9d99d87751d2ba3=mac.txt


Ah, interesting... Yesterday, I did something similar, a little helper that 
copies the breeze icons that are in a list and puts them in a qrc file :-)



Kate and KWrite call then this helper function after the initial QApplication 
construction:

https://quickgit.kde.org/?p=kate.git=blob=75b9d81be88aac55a689ca99adc9a5e0ae0bb1d3=1486c0e69df54e955e25223ff9d99d87751d2ba3=icons.h

The nice thing: that helper is always compiled in, that means you can test it 
with a normal compiled Kate/KWrite.

This for sure can be tuned to just pack the right breeze icons in that you 
need, but ATM even breeze lacks some icons
we use in KWrite/Kate/KTextEditor (or perhaps even some other frameworks).

All in all, the Mac and Windows port need no magic defines ATM, at least none I 
am aware off,
and no non-native magic (if you ignore that we use cmake/python/perl for some 
stuff).


Very, very nice!

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Impressive! And cool to see another project using the cmake externals
> approach, I can copy a lot of it for Krita 3, I think. How are you
> handling icons? Bundling the breeze theme, or putting the icons in resource
> files?
as I was lazy, I just compiled complete breeze into a binary rcc file like done 
in mac.txt: (search for the rcc calls)

https://quickgit.kde.org/?p=kate.git=blob=275a28d36b132f0f5d3963ae40b451d264bae3a5=1486c0e69df54e955e25223ff9d99d87751d2ba3=mac.txt

Kate and KWrite call then this helper function after the initial QApplication 
construction:

https://quickgit.kde.org/?p=kate.git=blob=75b9d81be88aac55a689ca99adc9a5e0ae0bb1d3=1486c0e69df54e955e25223ff9d99d87751d2ba3=icons.h

The nice thing: that helper is always compiled in, that means you can test it 
with a normal compiled Kate/KWrite.

This for sure can be tuned to just pack the right breeze icons in that you 
need, but ATM even breeze lacks some icons
we use in KWrite/Kate/KTextEditor (or perhaps even some other frameworks).

All in all, the Mac and Windows port need no magic defines ATM, at least none I 
am aware off,
and no non-native magic (if you ignore that we use cmake/python/perl for some 
stuff).

Greetings
Christoph

> 
> --
> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
> 
> On Thu, 22 Oct 2015, Christoph Cullmann wrote:
> 
>> Hi,
>>
>> btw., a preliminary self contained Kate for Windows can be found here:
>>
>> ftp://cullmann.io/cullmann/
>>
>> Created with the CMake file from this repo by Kåre Särs
>>
>> https://quickgit.kde.org/?p=scratch%2Fsars%2Fkate-windows.git=tree
>>
>> Plain Qt, normal Visual Studio, can be deployed without global stuff.
>> (you need the Visual Studio redist package, thought, or you bundle that .dll
>> in the zip, too)
>>
>> ZIP is only around 30MB, I think that is not that bad, no real need to spend
>> time on sharing stuff.
>>
>> Greetings
>> Christoph
>>
>> - Am 22. Okt 2015 um 8:39 schrieb cullmann cullm...@absint.com:
>>
>>> Hi,
>>> 
 Am 21.10.2015 um 01:19 schrieb Aleix Pol:
> On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:
>>> Christoph Cullmann  hat am 20. Oktober 2015 um 
>>> 16:49
>>> geschrieben:
>>> That works only, if the applications bundle their ui files in resources,
>>> too, otherwise, they just won't be found
>>> and the applications break, unless you patch again Qt to look in
>>> non-standard locations.
>> yes, the following patch
>> https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
>> is a workaround to fix some of the issues.
> That's why Christoph is saying: "unless you patch again Qt to look in
> non-standard locations.".
 umbrello for example depends on about 50 other libraries and packages
 https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
 Not patching Qt requires to repack every single package :-(, by either
 hacking the cmake build system to use different install locations or to
 reorder the installed files after cmake installing.
 
 Having Qt support for "standard linux path layout" for example by
 extending qt.conf to support QStandardPath (qt.conf is already required
 for KDE on Windows) shortcuts this repackaging need completly.
>>> I at least fixed already all frameworks required by the current Kate build
>>> (beside that KIO slave don't work atm and I guess
>>> I missed 1-2 files still not in resources):
>>> 
>>> kconfig
>>> kguiaddons
>>> ki18n
>>> kitemviews
>>> sonnet
>>> kwindowsystem
>>> kwidgetsaddons
>>> kcompletion
>>> kdbusaddons
>>> karchive
>>> kcoreaddons
>>> kjobwidgets
>>> kcrash
>>> kservice
>>> kcodecs
>>> kauth
>>> kconfigwidgets
>>> kiconthemes
>>> ktextwidgets
>>> kglobalaccel
>>> kxmlgui
>>> kbookmarks
>>> solid
>>> kio
>>> kparts
>>> ktexteditor
>>> 
>>> That means they now by "default" just work, if you use the master branch.
>>> More frameworks to go, for sure, but that is really doable ;=)
>>> 
>>> Greetings
>>> Christoph
>>> 
>>> --
>>> - Dr.-Ing. Christoph Cullmann -
>>> AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
>>> Science Park 1 Tel:   +49-681-38360-22
>>> 66123 Saarbrücken  Fax:   +49-681-38360-20
>>> GERMANYWWW:   http://www.AbsInt.com
>>> 
>>> Geschäftsführung: Dr.-Ing. Christian Ferdinand
>>> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
>>> ___
>>> Kde-frameworks-devel mailing list
>>> Kde-frameworks-devel@kde.org
>>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>>
>> --
>> - Dr.-Ing. Christoph Cullmann 

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> On Thu, 22 Oct 2015, Christoph Cullmann wrote:
> 
>> Hi,
>>
>>> Impressive! And cool to see another project using the cmake externals
>>> approach, I can copy a lot of it for Krita 3, I think. How are you
>>> handling icons? Bundling the breeze theme, or putting the icons in resource
>>> files?
>> as I was lazy, I just compiled complete breeze into a binary rcc file like 
>> done
>> in mac.txt: (search for the rcc calls)
>>
>> https://quickgit.kde.org/?p=kate.git=blob=275a28d36b132f0f5d3963ae40b451d264bae3a5=1486c0e69df54e955e25223ff9d99d87751d2ba3=mac.txt
> 
> Ah, interesting... Yesterday, I did something similar, a little helper that
> copies the breeze icons that are in a list and puts them in a qrc file :-)
I just use the rcc -project option for that, to pack all files in the current 
dir ;=)

> 
>>
>> Kate and KWrite call then this helper function after the initial QApplication
>> construction:
>>
>> https://quickgit.kde.org/?p=kate.git=blob=75b9d81be88aac55a689ca99adc9a5e0ae0bb1d3=1486c0e69df54e955e25223ff9d99d87751d2ba3=icons.h
>>
>> The nice thing: that helper is always compiled in, that means you can test it
>> with a normal compiled Kate/KWrite.
>>
>> This for sure can be tuned to just pack the right breeze icons in that you 
>> need,
>> but ATM even breeze lacks some icons
>> we use in KWrite/Kate/KTextEditor (or perhaps even some other frameworks).
>>
>> All in all, the Mac and Windows port need no magic defines ATM, at least 
>> none I
>> am aware off,
>> and no non-native magic (if you ignore that we use cmake/python/perl for some
>> stuff).
> 
> Very, very nice!
And very simple ;=) And without ugly "BUNDLE_MODE_HACK" defines.

If such an approach seems reasonable, we could have some helper for this in a 
framework.
Perhaps the "breeze" framework could even just provide such an rcc and a little 
lib to
load it that can be used for people creating bundles/installers.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Boudewijn Rempt]

On Wed, 21 Oct 2015, Alexander Neundorf wrote:



Maybe Qt could be shared ?



No, no, no. Absolutely not. Every application on Windows should bring
its own dependencies and all of them. Any attempt at anything else is
a misguided deviation from the platform's way of working and will bring
nothing but problems.

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Hello,
> 
> On Wednesday 21 October 2015 09:26:35 Christoph Cullmann wrote:
>> Hi,



>> ;=) Yeah, fluffy, e.g. I would call dbus "non-reasonable", as it requires
>> some daemon to be running, even if we would have per application install
>> daemons. I would call stuff reasonable that is available if you add some
>> dynlib to your application bundle.
> 
> So yeah, confirms to me the hypothesis I was having of: runtime deps.
> 
>> > I suspect it has something to do with runtime dependencies? If not, what
>> > is unreasonable in kxmlgui dependencies? (as it seems to be the main
>> > culprit)
>> 
>> kxmlgui was just an example to show that there is potential to reduce the
>> dependencies. e.g. you have kglobalaccel, which is not that useful on
>> Windows/Mac, given you have there normally no dbus to have it working.
>> The same for kauth, which you only need because of KCM inside
>> kconfigwidgets, which close to zero applications will use that require
>> kxmlgui.
> 
> Again, very much tied to runtime dependencies.
> 
>> > If it is linked to runtime dependencies, I think you ought to not only
>> > look at the Tier but also the Type. Only frameworks of the "functional"
>> > type have no such dependencies.
>> 
>> Perhaps.
> 
> At that point it looks *very* likely it's about the runtime dependencies and
> so that's the Type of the framework which conveys that.

Yes, that's true, that is more or less all about runtime deps.

> 
>> But lets look at some concrete example, the dependencies for KWrite/Kate (at
>> the moment, without optional stuff):
>> 



>> I would like to fix the remaining regressions, e.g. have the io slaves
>> working without Qt hacks and have some generic way to bundle e.g. the
>> Breeze icon set in the bundle without having to take care in the
>> application about too much stuff.
> 
> Right, that's another point where we need some effort: tooling to help create
> this kind of bundles.

Yeah, ATM I think that is even not that much work.

With my latest 

https://quickgit.kde.org/?p=kate.git=blob=mac.txt

I can have a self contained KWrite or Kate on Mac with all stuff working beside
KIO slaves + any DBus related things. That should work for any other "simple"
KDE application just the same.

Neither to frameworks or kate/kwrite any patches or compile time switches are 
needed,
you just need a patched macdeployqt, but the patch should go upstream, I hope:

https://bugreports.qt.io/browse/QTBUG-48836

For Windows, that is even "easier" as you can just copy together the .dll's 
there without
complex otool hacking ;)

To automate this to e.g. let the CI spill out .dmg files should be easy.

Still, a lot of fine tuning is needed. ATM the deployment will just move all 
plugins inside,
leading to stuff like WebKit in my .dmg file which is not needed. And one needs 
to solve
the KIO stuff, without resorting to patch Qt.

> 
> Anyway, to get back to the thing which prompted my involvement in that thread.
> No, we're not pretending stuff is available easily on every platform. We even
> put in place mechanisms to communicate how painful it is for a third party to
> embark something: Tiers and Types. This discussion also confirms to me that
> people generally somewhat know about the tier, but not the type.
> 
> For bundling, the closer you are to the bottom right corner[*] the easier, the
> further away of that corner the more problems you should expect.
> 
> And then, three areas of efforts which we are missing right now in Frameworks:
> - systematically try to reduce the tier and type of our frameworks (the
> maturity direction I was talking about);
> - for the frameworks of type "integration" more systematically make sure they
> work on other platforms than Linux (e.g. wouldn't it be nice if kglobalaccel
> would work without D-Bus on Windows using platform facilities?);
> - create tooling to help people to create Windows or Mac bundles for their
> applications.
+1 for that

> 
> To me, if the community manages to tackle those three challenges, it will be a
> higher path forward than playing with build time knobs which might lead to
> feature loss or API changes (which I already mentioned I consider as a lesser
> path).
Still, the first thing to have is to make it easy for people to actually
compile the stuff and improve it on non-linux machines.
And for that, perhaps, some more low level buildsystem knobs might be needed in 
the short term.
But perhaps nothing is needed, lets see.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts 

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

>> What's important to realize is that deployment under Windows works different
> 
>> to deployment under Linux: In Linux, you have the package manager which
> 
>> automatically drags in all correct dependencies and you are fine.
> 
>> 
> 
>> In Windows, such a package manager does not exist. KDE tried to create
> 
>> such a package manager through the emerge/KDE Windows installer, but
> 
>> this is non-standard [on Windows] and simply not what users want.
> 
>> 
> 
>> Speaking for Kate or KWrite, we want one downloadable .zip/installer that
> 
>> just installs Kate/KWrite, and that's it. Yes, that implies that Kile,
> 
>> KDevelop, ... will again install Qt and all the required frameworks, but
> 
>> this is how things
> 
>> work on Windows, and that's perfectly fine (size is not an issue).
> 
> 
> 
> Maybe Qt could be shared ?
Maybe, but actually, even with the most dumb application bundle I have created 
ATM
all stuff together is around 50 MB compressed and installed 125 MB.

This includes a more or less complete Qt (with webkit, some debug plugins and 
other not used stuff) +
xx of our frameworks and a complete Breeze icon set (and most of the kate 
plugins).

gekko:Contents cullmann$ du -ms *
92  Frameworks
1   Info.plist
1   MacOS
22  PlugIns
11  Resources

gekko:Contents cullmann$ du -ms .
124 .

You can shrink that, by not bundling things you don't need, and I guess that 
could save
again 40 - 50 MB.

Still, on a modern machine that means not much, given one MP3 album or some raw 
photos are already larger.

On a Windows machine, 125 MB are a Joke ;=)
On some Mac, yeah, you have not that much space, but alone Firefox or Chrome 
are here > 150 MB. I don't think
the current bundle size is that ridiculous.

And the big benefit: One can install my alpha crashy something quality Kate 
bundle with its Qt something version
and some imaginary Krita bundle that is installed in parallel will NOT be 
borked!

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Kevin Ottens]

Hello,

On Wednesday 21 October 2015 21:06:02 Christoph Cullmann wrote:
> >> > If it is linked to runtime dependencies, I think you ought to not only
> >> > look at the Tier but also the Type. Only frameworks of the "functional"
> >> > type have no such dependencies.
> >> 
> >> Perhaps.
> > 
> > At that point it looks *very* likely it's about the runtime dependencies
> > and so that's the Type of the framework which conveys that.
> 
> Yes, that's true, that is more or less all about runtime deps.
> 
> [...]
> >> I would like to fix the remaining regressions, e.g. have the io slaves
> >> working without Qt hacks and have some generic way to bundle e.g. the
> >> Breeze icon set in the bundle without having to take care in the
> >> application about too much stuff.
> > 
> > Right, that's another point where we need some effort: tooling to help
> > create this kind of bundles.
> 
> Yeah, ATM I think that is even not that much work.

Good news then. :-)

> With my latest
> 
> https://quickgit.kde.org/?p=kate.git=blob=mac.txt
> 
> I can have a self contained KWrite or Kate on Mac with all stuff working
> beside KIO slaves + any DBus related things. That should work for any other
> "simple" KDE application just the same.
> 
> Neither to frameworks or kate/kwrite any patches or compile time switches
> are needed, you just need a patched macdeployqt, but the patch should go
> upstream, I hope:
> 
> https://bugreports.qt.io/browse/QTBUG-48836
> 
> For Windows, that is even "easier" as you can just copy together the .dll's
> there without complex otool hacking ;)
> 
> To automate this to e.g. let the CI spill out .dmg files should be easy.
> 
> Still, a lot of fine tuning is needed. ATM the deployment will just move all
> plugins inside, leading to stuff like WebKit in my .dmg file which is not
> needed. And one needs to solve the KIO stuff, without resorting to patch
> Qt.

Yes, but still, thanks to your moves we're not that far off it seems. That's 
good.

> > Anyway, to get back to the thing which prompted my involvement in that
> > thread. No, we're not pretending stuff is available easily on every
> > platform. We even put in place mechanisms to communicate how painful it
> > is for a third party to embark something: Tiers and Types. This
> > discussion also confirms to me that people generally somewhat know about
> > the tier, but not the type.
> > 
> > For bundling, the closer you are to the bottom right corner[*] the easier,
> > the further away of that corner the more problems you should expect.
> > 
> > And then, three areas of efforts which we are missing right now in
> > Frameworks: - systematically try to reduce the tier and type of our
> > frameworks (the maturity direction I was talking about);
> > - for the frameworks of type "integration" more systematically make sure
> > they work on other platforms than Linux (e.g. wouldn't it be nice if
> > kglobalaccel would work without D-Bus on Windows using platform
> > facilities?);
> > - create tooling to help people to create Windows or Mac bundles for their
> > applications.
> 
> +1 for that

Of course the problem is as usual, who will step up and do it? :-)

> > To me, if the community manages to tackle those three challenges, it will
> > be a higher path forward than playing with build time knobs which might
> > lead to feature loss or API changes (which I already mentioned I consider
> > as a lesser path).
> 
> Still, the first thing to have is to make it easy for people to actually
> compile the stuff and improve it on non-linux machines.
> And for that, perhaps, some more low level buildsystem knobs might be needed
> in the short term. But perhaps nothing is needed, lets see.

My concern there is more the fact that this kind of "short term" or 
"temporary" solutions tend to become permanent. As long as it is causing pain 
you can hope someone will look at it and try to fix it... and indeed, see what 
you achieved! ;-)
But if you put in place something short term lifting the immediate pain, 
people will learn to live with it and it'll stay. I hope we'll avoid that.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Alexander Neundorf]

On Wednesday, October 21, 2015 13:08:46 Dominik Haumann wrote:
> On Tue, Oct 20, 2015 at 8:23 PM, Christoph Cullmann 
 wrote:
> > I think that is more or less what we had in the past with the "kdewin"
> > installer, that is like the cygwin installer pulling in all stuff you
> > need and a set of applications in some common prefix.
> > 
> > I am not sure that was such a success, compared to what e.g. Krita,
> > Marble, Digikam and others do: individual self-contained installers 
(or
> > bundles).
> > 
> > I really think we should focus on making frameworks fit for that and 
not
> > rebuilding some "micro-distro" with online installer for that operating
> > systems.
> I fully support that, based on the following reasoning:
> 
> What's important to realize is that deployment under Windows works 
different
> to deployment under Linux: In Linux, you have the package manager 
which
> automatically drags in all correct dependencies and you are fine.
> 
> In Windows, such a package manager does not exist. KDE tried to 
create
> such a package manager through the emerge/KDE Windows installer, 
but
> this is non-standard [on Windows] and simply not what users want.
> 
> Speaking for Kate or KWrite, we want one downloadable .zip/installer 
that
> just installs Kate/KWrite, and that's it. Yes, that implies that Kile,
> KDevelop, ... will again install Qt and all the required frameworks, but
> this is how things
> work on Windows, and that's perfectly fine (size is not an issue).

Maybe Qt could be shared ?

> So thanks a lot Christoph for your work on making self-contained 
frameworks,
> that's definitely the correct solution.
> 
> Incidentally, this solution is probably also desirable for commercial 
usage
> of our KF5 frameworks: Commercial applications often want to ship
> everything themselves, and having self-contained libraries that do not
> depend on additional files in some other installation folder does 
exactly
> this.

I can confirm that.

Alex

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

Re: Question about goal of Windows/Mac frameworks

[Alexander Neundorf]

On Wednesday, October 21, 2015 22:48:52 Christoph Cullmann wrote:
> Hi,
> 
> > On Wednesday, October 21, 2015 22:12:00 Christoph Cullmann 
wrote:
> > 
> > ...
> > 
> >> And the big benefit: One can install my alpha crashy something 
quality
> >> Kate
> >> 
> >> bundle with its Qt something version and some imaginary Krita 
bundle that
> >> 
> >> is installed in parallel will NOT be borked!
> > 
> > are you more or less arguing against all the benefits of shared 
libraries
> > as found in Linux distributions ? ;-)
> 
> if you are not part of the distro packages or some build service that
> creates pacakges for ALL distros * versions you want to support: yes.
> 
> I package our company's software now since close to 10 years for
> Windows/Linux and no, never ever there was any chance to use 
system
> libraries beside the most basic ones, and even there, to support old
> systems, you will need to ship some local copies (starting from 
libstdc++
> to libxcb). To use something like the Qt libraries shipped with the 
distros
> is just out of question, if you try to target stuff >= Red Hat 5 with ONE
> package.

Same here, we do the same, also for RHEL >= 5.
OT: But we get along without shipping libstdc++ or similar low level 
libraries.
What we do is, where necessary, tweak/comment out configure checks 
which would make our software require newer versions of other libs.

Alex

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

Re: Question about goal of Windows/Mac frameworks

[Alexander Neundorf]

On Wednesday, October 21, 2015 22:12:00 Christoph Cullmann 
wrote:
...
> And the big benefit: One can install my alpha crashy something 
quality Kate
> bundle with its Qt something version and some imaginary Krita 
bundle that
> is installed in parallel will NOT be borked!

are you more or less arguing against all the benefits of shared 
libraries as found in Linux distributions ? ;-)

Alex

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> On Wednesday, October 21, 2015 22:12:00 Christoph Cullmann wrote:
> 
> ...
> 
>> And the big benefit: One can install my alpha crashy something quality Kate
> 
>> bundle with its Qt something version and some imaginary Krita bundle that
> 
>> is installed in parallel will NOT be borked!
> 
> 
> 
> are you more or less arguing against all the benefits of shared libraries as
> found in Linux distributions ? ;-)
if you are not part of the distro packages or some build service that creates 
pacakges
for ALL distros * versions you want to support: yes.

I package our company's software now since close to 10 years for Windows/Linux 
and
no, never ever there was any chance to use system libraries beside the most 
basic ones,
and even there, to support old systems, you will need to ship some local copies 
(starting
from libstdc++ to libxcb). To use something like the Qt libraries shipped with 
the distros is
just out of question, if you try to target stuff >= Red Hat 5 with ONE package.

On Windows you anyway are used to ship everything, starting the with Visual 
Studio runtime libs.
Which btw. gives you nice freedom, like using more or less the latest Visual 
Studio and still
deploy on relatively old Windows Versions, like XP (ok, that time is now over 
even there with current
visual studios, but still).

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Kevin Ottens]

Hello,

On Wednesday 21 October 2015 08:13:42 Christoph Cullmann wrote:
> > On Tuesday 20 October 2015 19:49:54 Aleix Pol wrote:
> >> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
> >> only be advertised as available on a platform if they are just require
> >> Qt or other available dependencies on the platform". For example,
> >> requiring libssh could be an acceptable dependency.
> > 
> > Isn't it a rephrased definition of Tier 1?
> > 
> > Tier 1 frameworks are supposed to depend only on Qt and platform
> > libraries.
> 
> Yeah, wrong again :/
> Including other frameworks, I meant.
> 
> But beside that, perhaps 3) is not even needed given 2) says "Can be
> self-contained shipped in an application bundle (self-installer/mac app
> bundle)." That more or less implies you only have "reasonable" dependencies
> that can be bundled, too.

I'm not sure that's helping. What is "reasonable"? :-)

I suspect it has something to do with runtime dependencies? If not, what is 
unreasonable in kxmlgui dependencies? (as it seems to be the main culprit)

If it is linked to runtime dependencies, I think you ought to not only look at 
the Tier but also the Type. Only frameworks of the "functional" type have no 
such dependencies.

Cheers.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Hello,
> 
> On Wednesday 21 October 2015 08:13:42 Christoph Cullmann wrote:
>> > On Tuesday 20 October 2015 19:49:54 Aleix Pol wrote:
>> >> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
>> >> only be advertised as available on a platform if they are just require
>> >> Qt or other available dependencies on the platform". For example,
>> >> requiring libssh could be an acceptable dependency.
>> > 
>> > Isn't it a rephrased definition of Tier 1?
>> > 
>> > Tier 1 frameworks are supposed to depend only on Qt and platform
>> > libraries.
>> 
>> Yeah, wrong again :/
>> Including other frameworks, I meant.
>> 
>> But beside that, perhaps 3) is not even needed given 2) says "Can be
>> self-contained shipped in an application bundle (self-installer/mac app
>> bundle)." That more or less implies you only have "reasonable" dependencies
>> that can be bundled, too.
> 
> I'm not sure that's helping. What is "reasonable"? :-)
;=) Yeah, fluffy, e.g. I would call dbus "non-reasonable", as it requires some 
daemon
to be running, even if we would have per application install daemons. I would 
call stuff
reasonable that is available if you add some dynlib to your application bundle.

> 
> I suspect it has something to do with runtime dependencies? If not, what is
> unreasonable in kxmlgui dependencies? (as it seems to be the main culprit)
kxmlgui was just an example to show that there is potential to reduce the 
dependencies.
e.g. you have kglobalaccel, which is not that useful on Windows/Mac, given you 
have there
normally no dbus to have it working.
The same for kauth, which you only need because of KCM inside kconfigwidgets, 
which close to zero
applications will use that require kxmlgui.

> 
> If it is linked to runtime dependencies, I think you ought to not only look at
> the Tier but also the Type. Only frameworks of the "functional" type have no
> such dependencies.
Perhaps.
But lets look at some concrete example, the dependencies for KWrite/Kate (at 
the moment, without optional stuff):

build_framework extra-cmake-modules
build_framework kconfig
build_framework kguiaddons
build_framework ki18n
build_framework kitemviews
build_framework sonnet
build_framework kwindowsystem
build_framework kwidgetsaddons
build_framework kcompletion
build_framework kdbusaddons
build_framework karchive
build_framework kcoreaddons
build_framework kjobwidgets
build_framework kcrash
build_framework kservice
build_framework kcodecs
build_framework kauth
build_framework kconfigwidgets
build_framework kiconthemes
build_framework ktextwidgets
build_framework kglobalaccel
build_framework kxmlgui
build_framework kbookmarks
build_framework solid
build_framework kio
build_framework kparts
build_framework ktexteditor

Even with all these frameworks (even very high tier ones), ATM, all stuff is 
self-contained bundleable inside
the final KWrite/Kate bundle/installer (even with some reasonable size, between 
20-30 MB of
target zip file).

Only some stuff has "feature regressions", like kglobalaccel (no global daemon 
support as requires dbus),
kio (no wallet and other stuff as requires dbus, ATM no working slaves as 
.protocol files not found
without Qt hacks to standardpaths).

All other stuff is now more or less just deployable by having the 
.dll/.so/.dylib in the bundle,
given I put all stuff in .qrc files there (I just missed some small pics/files 
in some frameworks ATM,
need to fix that ;=) Even kxmlgui ;=)

I would like to fix the remaining regressions, e.g. have the io slaves working 
without Qt hacks and
have some generic way to bundle e.g. the Breeze icon set in the bundle without 
having to take care in
the application about too much stuff.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Ralf Habacker]

> Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
> geschrieben:
 
> That works only, if the applications bundle their ui files in resources, too,
> otherwise, they just won't be found
> and the applications break, unless you patch again Qt to look in non-standard
> locations.
yes, the following patch
https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
is a workaround to fix some of the issues.

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

Re: Question about goal of Windows/Mac frameworks

[Gregor M]

I think that is more or less what we had in the past with the "kdewin"
installer,
that is like the cygwin installer pulling in all stuff you need and a
set of applications
in some common prefix.

I am not sure that was such a success, compared to what e.g. Krita,
Marble, Digikam and others do:
individual self-contained installers (or bundles).

I really think we should focus on making frameworks fit for that and 
not
rebuilding some "micro-distro" with online installer for that operating 
systems.


But that is just my opinion, perhaps I am wrong with that.


Hi Christoph,

as a long-term user of free software under Windows I can confirm your 
impression. Applications which are shipped as self-contained installers 
just work out-of-the-box and do not conflict with other applications on 
the system which makes them pleasant to use.


(One disadvantage is that each of them has to be updated individually 
but that's a general problem with the installers approach of how it is 
done under Windows)


Gregor

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

Re: Question about goal of Windows/Mac frameworks

[Ralf Habacker]

Am 21.10.2015 um 08:14 schrieb Christoph Cullmann:
> Hi,
>
>>> Aleix Pol  hat am 20. Oktober 2015 um 19:49 geschrieben:
>>> Regarding dbus especifically, I see the problem in 2). You can bundle
>>> it, but then if it's already ran by another process the other one will
>>> have to be used, which is where the dbus mess starts.
>> There is work in progress to provide dbus installations as standalone 
>> package or
>> bundled with an application on Windows. See
>> https://bugs.freedesktop.org/show_bug.cgi?id=92080. Version 2.18 of the
>> umbrello installer [1] will have a bundled dbus-daemon providing an install
>> path limited session bus, which is separated from the main session bus. An
>> alternative will be to install a standalone dbus package [2] which can be 
>> used
>> by single KDE applications installed by a separate installers. Each KDE
>> application can be configured to use the bundled dbus or the standalone.
> whereas I think that is great news to deploy stuff that really requires dbus,
> actually, e.g. for the umbrello use case: why do I need it at all?g
The last time I build umbrello with kf5 (version 5.11) dbus was required
to run khelpcenter and open/save file dialogs and for remote control.
http://download.opensuse.org/repositories/home:/rhabacker:/branches:/windows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-installer-2.18.99-4.1.noarch.rpm
(you may open this rpm with ark of 7zip file manager to get the installer)
Ralf

>
> Greetings
> Christoph
>

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Am 21.10.2015 um 08:14 schrieb Christoph Cullmann:
>> Hi,
>>
 Aleix Pol  hat am 20. Oktober 2015 um 19:49 geschrieben:
 Regarding dbus especifically, I see the problem in 2). You can bundle
 it, but then if it's already ran by another process the other one will
 have to be used, which is where the dbus mess starts.
>>> There is work in progress to provide dbus installations as standalone 
>>> package or
>>> bundled with an application on Windows. See
>>> https://bugs.freedesktop.org/show_bug.cgi?id=92080. Version 2.18 of the
>>> umbrello installer [1] will have a bundled dbus-daemon providing an install
>>> path limited session bus, which is separated from the main session bus. An
>>> alternative will be to install a standalone dbus package [2] which can be 
>>> used
>>> by single KDE applications installed by a separate installers. Each KDE
>>> application can be configured to use the bundled dbus or the standalone.
>> whereas I think that is great news to deploy stuff that really requires dbus,
>> actually, e.g. for the umbrello use case: why do I need it at all?g
> The last time I build umbrello with kf5 (version 5.11) dbus was required
> to run khelpcenter and open/save file dialogs and for remote control.
> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/windows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-installer-2.18.99-4.1.noarch.rpm
> (you may open this rpm with ark of 7zip file manager to get the installer)
open/save stuff is fixed in KF5 master
But yes, khelpcenter (if it is shipped) might need fixing and remote control 
for sure.
That's the same state as for Kate ATM.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Dominik Haumann]

On Tue, Oct 20, 2015 at 8:23 PM, Christoph Cullmann  wrote:
> I think that is more or less what we had in the past with the "kdewin" 
> installer,
> that is like the cygwin installer pulling in all stuff you need and a set of 
> applications
> in some common prefix.
>
> I am not sure that was such a success, compared to what e.g. Krita, Marble, 
> Digikam and others do:
> individual self-contained installers (or bundles).
>
> I really think we should focus on making frameworks fit for that and not
> rebuilding some "micro-distro" with online installer for that operating 
> systems.

I fully support that, based on the following reasoning:

What's important to realize is that deployment under Windows works different
to deployment under Linux: In Linux, you have the package manager which
automatically drags in all correct dependencies and you are fine.

In Windows, such a package manager does not exist. KDE tried to create
such a package manager through the emerge/KDE Windows installer, but
this is non-standard [on Windows] and simply not what users want.

Speaking for Kate or KWrite, we want one downloadable .zip/installer that
just installs Kate/KWrite, and that's it. Yes, that implies that Kile, KDevelop,
... will again install Qt and all the required frameworks, but this is
how things
work on Windows, and that's perfectly fine (size is not an issue).

So thanks a lot Christoph for your work on making self-contained frameworks,
that's definitely the correct solution.

Incidentally, this solution is probably also desirable for commercial usage of
our KF5 frameworks: Commercial applications often want to ship everything
themselves, and having self-contained libraries that do not depend on additional
files in some other installation folder does exactly this.
In other words: having self-contained libraries is also a plus on Linux.

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

>> Aleix Pol  hat am 20. Oktober 2015 um 19:49 geschrieben:
>> Regarding dbus especifically, I see the problem in 2). You can bundle
>> it, but then if it's already ran by another process the other one will
>> have to be used, which is where the dbus mess starts.
> There is work in progress to provide dbus installations as standalone package 
> or
> bundled with an application on Windows. See
> https://bugs.freedesktop.org/show_bug.cgi?id=92080. Version 2.18 of the
> umbrello installer [1] will have a bundled dbus-daemon providing an install
> path limited session bus, which is separated from the main session bus. An
> alternative will be to install a standalone dbus package [2] which can be used
> by single KDE applications installed by a separate installers. Each KDE
> application can be configured to use the bundled dbus or the standalone.
whereas I think that is great news to deploy stuff that really requires dbus,
actually, e.g. for the umbrello use case: why do I need it at all?

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Hello,
> 
> On Tuesday 20 October 2015 19:49:54 Aleix Pol wrote:
>> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
>> only be advertised as available on a platform if they are just require
>> Qt or other available dependencies on the platform". For example,
>> requiring libssh could be an acceptable dependency.
> 
> Isn't it a rephrased definition of Tier 1?
> 
> Tier 1 frameworks are supposed to depend only on Qt and platform libraries.
Yeah, wrong again :/
Including other frameworks, I meant.

But beside that, perhaps 3) is not even needed given 2) says "Can be 
self-contained shipped in an application bundle (self-installer/mac app 
bundle)."
That more or less implies you only have "reasonable" dependencies that can be 
bundled, too.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Alexander Neundorf]

On Tuesday, October 20, 2015 20:23:00 Christoph Cullmann wrote:
> Hi,
> 
> > Christoph.
> > 
> > I have had similar goals for a while, but haven't reached the point
> > that I was having much success yet in that regard. One thing to keep
> > in mind when developing installers, Qt Installer Framework. I did a
> > quick test with attica on OS X I can put on reviewboard to see what
> > you think. I added a few lines to CMakeLists.txt to make it so you can
> > do make package, and it uses CPack and Qt Installer Framework to
> > create an installer application which can be used to download both
> > attica and attica-devel packages for OSX. I bet we could put together
> > a "meta" package for at least KF5 and maybe more which would 
consist
> > of a CMakeLists.txt and a bunch of git clones beneath it could be 
used
> > to create one OSX or Windows installer that could then be used to
> > download applications and all their dependencies. I wasn't sure 
how to
> > add dependency information to the result of CPack's QIFW 
generator,
> > but it should be doable.
> > 
> > The result of all of that would be one tool for OS X and a similar one
> > for Windows that work exactly like the Qt online installers. Qt's
> > online installers are meant for developers though, not end users, so
> > we may need to improve QIF itself to make the resulting installer 
more
> > user friendly, we'll see. I meant to blog about all of this a week or
> > so ago, but haven't gotten around to it. What do you think of the idea
> > in general though?
> 
> I am not really a fan of that idea, to be honest.
> 
> I think that is more or less what we had in the past with the "kdewin"
> installer, that is like the cygwin installer pulling in all stuff you need
> and a set of applications in some common prefix.
> 
> I am not sure that was such a success, compared to what e.g. Krita, 
Marble,
> Digikam and others do: individual self-contained installers (or 
bundles).
> 
> I really think we should focus on making frameworks fit for that and 
not
> rebuilding some "micro-distro" with online installer for that operating
> systems.
> 
> But that is just my opinion, perhaps I am wrong with that.

I fully agree with your POV.

Alex

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Hi,
> With my Android hat on I very much welcome the initiative. Android is
> more limited in this regard, as you will mostly always want to have
> split packages there and it's how we've been working since the
> beginning.
> 
> I think that for us Qt is a safe base in general. relying on other 3rd
> parties makes things a bit more complex. (e.g. dbus or gstreamer) It's
> always arguable that it is possible to run, but then it can be a
> burden. While on Linux it's preferable to leverage on the system
> infrastructure, we can't expect these to be available elsewhere.
> 
> I can agree to the 3 goals you mentioned, but they feel fuzzy:
> 1) Fully agreed
1) Stock Qt

> 2) What's Global stuff? This could be phrased as: "Frameworks should
> only require resources that can be located with QStandardPaths and can
> be distributed in bundles."
Badly phrased, yes, I think 2) is more like:

2) Can be self-contained shipped in an application bundle (self-installer/mac 
app bundle).

> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
> only be advertised as available on a platform if they are just require
> Qt or other available dependencies on the platform". For example,
> requiring libssh could be an acceptable dependency.
> 
> Regarding dbus especifically, I see the problem in 2). You can bundle
> it, but then if it's already ran by another process the other one will
> have to be used, which is where the dbus mess starts.
Yeah, 3) is perhaps more like:

3) Frameworks shall require only libraries shipped with the target operating 
system
per default (which is quiet well defined on Win/Mac, but not that well defined 
on Linux).

That additional stuff might be useful/recommended is clear, IMHO, like you can 
have
nice git integration if you have libgit2 for KTextEditor, but it works without.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Jeremy Whiting]

Christoph,

I'm not trying to argue against having applications come in complete
bundles at all. That is a worthy goal also actually, it's just not the
direction I was headed in. You've made a lot more progress in this
regard than I had though tbh. I see the kdewin installer as something
that went away because it was tricky to set up, had a bus number of
one (I think only Saro was creating repositories for it iirc), so it
fell by the wayside at some point. I did use it to install my favorite
kde utilities on windows whenever I was stuck on windows for various
reasons though. It was useful to install ksnapshot, filelight, etc.
and have them use the same copy of kdelibs. Maybe with frameworks it's
not that important to share libraries between applications though. I'm
not sure.

I can understand arguments for both ways of doing things. Having each
application have it's own copy of Qt, KF5, etc. makes it possible to
know that those versions have been tested with the application code to
make sure it runs well etc. If applications are sharing one copy of Qt
and one of them upgrades it, it's not guaranteed to work the same way
as an older version (it's supposed to work, but I've seen enough
e-mail about Qt 5.x breaks plasma where it worked with Qt 5.x-1 to
know this isn't always the case in reality.)

Also, the work you're doing to make frameworks use bundled resources
will help both of the above use cases, so that's definitely an
improvement in my opinion.

I can see advanced users either using macports, fink, homebrew or a
download and install x,y,z and share libraries to install many of our
applications. I can also see the same power users recommending
individual applications to their relatives (moms, grandmothers, etc.)
using single application installers as you described. "Here mom,
download this one bundle to install kxstitch on your windows laptop."
etc. So there are advantages to both/all ways of going forward I
think.

BR,
Jeremy

On Tue, Oct 20, 2015 at 1:19 PM, Alexander Neundorf  wrote:
> On Tuesday, October 20, 2015 20:23:00 Christoph Cullmann wrote:
>
>> Hi,
>
>>
>
>> > Christoph.
>
>> >
>
>> > I have had similar goals for a while, but haven't reached the point
>
>> > that I was having much success yet in that regard. One thing to keep
>
>> > in mind when developing installers, Qt Installer Framework. I did a
>
>> > quick test with attica on OS X I can put on reviewboard to see what
>
>> > you think. I added a few lines to CMakeLists.txt to make it so you can
>
>> > do make package, and it uses CPack and Qt Installer Framework to
>
>> > create an installer application which can be used to download both
>
>> > attica and attica-devel packages for OSX. I bet we could put together
>
>> > a "meta" package for at least KF5 and maybe more which would consist
>
>> > of a CMakeLists.txt and a bunch of git clones beneath it could be used
>
>> > to create one OSX or Windows installer that could then be used to
>
>> > download applications and all their dependencies. I wasn't sure how to
>
>> > add dependency information to the result of CPack's QIFW generator,
>
>> > but it should be doable.
>
>> >
>
>> > The result of all of that would be one tool for OS X and a similar one
>
>> > for Windows that work exactly like the Qt online installers. Qt's
>
>> > online installers are meant for developers though, not end users, so
>
>> > we may need to improve QIF itself to make the resulting installer more
>
>> > user friendly, we'll see. I meant to blog about all of this a week or
>
>> > so ago, but haven't gotten around to it. What do you think of the idea
>
>> > in general though?
>
>>
>
>> I am not really a fan of that idea, to be honest.
>
>>
>
>> I think that is more or less what we had in the past with the "kdewin"
>
>> installer, that is like the cygwin installer pulling in all stuff you need
>
>> and a set of applications in some common prefix.
>
>>
>
>> I am not sure that was such a success, compared to what e.g. Krita,
>> Marble,
>
>> Digikam and others do: individual self-contained installers (or bundles).
>
>>
>
>> I really think we should focus on making frameworks fit for that and not
>
>> rebuilding some "micro-distro" with online installer for that operating
>
>> systems.
>
>>
>
>> But that is just my opinion, perhaps I am wrong with that.
>
>
>
> I fully agree with your POV.
>
>
>
> Alex
>
>
>
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Jeremy Whiting]

Christoph.

I have had similar goals for a while, but haven't reached the point
that I was having much success yet in that regard. One thing to keep
in mind when developing installers, Qt Installer Framework. I did a
quick test with attica on OS X I can put on reviewboard to see what
you think. I added a few lines to CMakeLists.txt to make it so you can
do make package, and it uses CPack and Qt Installer Framework to
create an installer application which can be used to download both
attica and attica-devel packages for OSX. I bet we could put together
a "meta" package for at least KF5 and maybe more which would consist
of a CMakeLists.txt and a bunch of git clones beneath it could be used
to create one OSX or Windows installer that could then be used to
download applications and all their dependencies. I wasn't sure how to
add dependency information to the result of CPack's QIFW generator,
but it should be doable.

The result of all of that would be one tool for OS X and a similar one
for Windows that work exactly like the Qt online installers. Qt's
online installers are meant for developers though, not end users, so
we may need to improve QIF itself to make the resulting installer more
user friendly, we'll see. I meant to blog about all of this a week or
so ago, but haven't gotten around to it. What do you think of the idea
in general though?

thanks,
Jeremy

On Tue, Oct 20, 2015 at 12:04 PM, Christoph Cullmann
 wrote:
> Hi,
>
>> Hi,
>> With my Android hat on I very much welcome the initiative. Android is
>> more limited in this regard, as you will mostly always want to have
>> split packages there and it's how we've been working since the
>> beginning.
>>
>> I think that for us Qt is a safe base in general. relying on other 3rd
>> parties makes things a bit more complex. (e.g. dbus or gstreamer) It's
>> always arguable that it is possible to run, but then it can be a
>> burden. While on Linux it's preferable to leverage on the system
>> infrastructure, we can't expect these to be available elsewhere.
>>
>> I can agree to the 3 goals you mentioned, but they feel fuzzy:
>> 1) Fully agreed
> 1) Stock Qt
>
>> 2) What's Global stuff? This could be phrased as: "Frameworks should
>> only require resources that can be located with QStandardPaths and can
>> be distributed in bundles."
> Badly phrased, yes, I think 2) is more like:
>
> 2) Can be self-contained shipped in an application bundle (self-installer/mac 
> app bundle).
>
>> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
>> only be advertised as available on a platform if they are just require
>> Qt or other available dependencies on the platform". For example,
>> requiring libssh could be an acceptable dependency.
>>
>> Regarding dbus especifically, I see the problem in 2). You can bundle
>> it, but then if it's already ran by another process the other one will
>> have to be used, which is where the dbus mess starts.
> Yeah, 3) is perhaps more like:
>
> 3) Frameworks shall require only libraries shipped with the target operating 
> system
> per default (which is quiet well defined on Win/Mac, but not that well 
> defined on Linux).
>
> That additional stuff might be useful/recommended is clear, IMHO, like you 
> can have
> nice git integration if you have libgit2 for KTextEditor, but it works 
> without.
>
> Greetings
> Christoph
>
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
> Science Park 1 Tel:   +49-681-38360-22
> 66123 Saarbrücken  Fax:   +49-681-38360-20
> GERMANYWWW:   http://www.AbsInt.com
> 
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Aleix Pol]

On Tue, Oct 20, 2015 at 4:49 PM, Christoph Cullmann  wrote:
> Hi,
>
> after some patching, we got around to a state that allows to e.g. use KWrite
> on Windows or Mac with stock frameworks master and stock Qt 5.5, without any 
> additional
> patches and no stuff like dbus running. (as standalone installer/bundles)
>
> To have KIO working, one needs to teach it how to find the .protocol files, 
> like
> ATM done by some patches to Qt by the Windows folks (or we avoid that by 
> embedding that
> info in the slaves in the plugin meta data), for icons you need to set the 
> icon lookup
> path + theme hardcoded.
>
> My question: What is the actual goal for frameworks on non-linux like (or 
> non-xdg conform)
> or whatever called operating systems?
>
> My personal current goal is to have them in at state that allows:
>
> 1) use stock Qt as base
> 2) have frameworks in a state that allows them to be used in application 
> standalone installer/app-bundle without global stuff required
> 3) avoid the use of non-existing stuff like the dbus session bus
>
> For the "make it easy to bundle" I patched some frameworks to support stuff 
> inside qt resources.
> (xmlgui for ui files, kconfig for global default config files)
>
> That works only, if the applications bundle their ui files in resources, too, 
> otherwise, they just won't be found
> and the applications break, unless you patch again Qt to look in non-standard 
> locations.
>
> For the "non-dbus" I made some stuff bit more "failure safe", if no bus is 
> around, on cost of features.
> (like for kio, no instant segfault anymore, just no working dbus related 
> stuff)
>
> Here the applications need a bit care, too, like not exit, if they can't 
> register on the bus.
>
> Is that just my personal goal or is that what we want to have as frameworks 
> goal on such operating systems?
> Would that make the stuff more usable for Krita for example?
>
> Greetings
> Christoph

Hi,
With my Android hat on I very much welcome the initiative. Android is
more limited in this regard, as you will mostly always want to have
split packages there and it's how we've been working since the
beginning.

I think that for us Qt is a safe base in general. relying on other 3rd
parties makes things a bit more complex. (e.g. dbus or gstreamer) It's
always arguable that it is possible to run, but then it can be a
burden. While on Linux it's preferable to leverage on the system
infrastructure, we can't expect these to be available elsewhere.

I can agree to the 3 goals you mentioned, but they feel fuzzy:
1) Fully agreed
2) What's Global stuff? This could be phrased as: "Frameworks should
only require resources that can be located with QStandardPaths and can
be distributed in bundles."
3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
only be advertised as available on a platform if they are just require
Qt or other available dependencies on the platform". For example,
requiring libssh could be an acceptable dependency.

Regarding dbus especifically, I see the problem in 2). You can bundle
it, but then if it's already ran by another process the other one will
have to be used, which is where the dbus mess starts.

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

Re: Question about goal of Windows/Mac frameworks

[Kevin Ottens]

Hello,

On Tuesday 20 October 2015 19:49:54 Aleix Pol wrote:
> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
> only be advertised as available on a platform if they are just require
> Qt or other available dependencies on the platform". For example,
> requiring libssh could be an acceptable dependency.

Isn't it a rephrased definition of Tier 1?

Tier 1 frameworks are supposed to depend only on Qt and platform libraries.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Ralf Habacker]

> Aleix Pol  hat am 20. Oktober 2015 um 19:49 geschrieben:
> Regarding dbus especifically, I see the problem in 2). You can bundle
> it, but then if it's already ran by another process the other one will
> have to be used, which is where the dbus mess starts.
 
There is work in progress to provide dbus installations as standalone package or
bundled with an application on Windows. See
https://bugs.freedesktop.org/show_bug.cgi?id=92080. Version 2.18 of  the
umbrello installer [1] will have a bundled dbus-daemon providing an install path
limited session bus, which is separated from the main session bus. An
alternative will be to install a standalone dbus package [2] which can be used
by single KDE applications installed  by a separate installers. Each KDE
application can be configured to use the bundled dbus or the standalone.
 
Regards
 Ralf
 
[1] Umbrello Windows Installer http://download.kde.org/stable/umbrello/latest/
 
[2] Prelimary DBus Installer
http://download.opensuse.org/repositories/home:/rhabacker:/branches:/windows:/mingw:/win32/openSUSE_13.1/noarch/mingw32-dbus-1-installer-1.10.0.da0737e-1.1.noarch.rpm
(Open with ark or 7zip File Manager to extract the contained installer)
 ___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Aleix Pol]

On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:
>> Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
>> geschrieben:
>
>> That works only, if the applications bundle their ui files in resources,
>> too, otherwise, they just won't be found
>> and the applications break, unless you patch again Qt to look in
>> non-standard locations.
> yes, the following patch
> https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
> is a workaround to fix some of the issues.

That's why Christoph is saying: "unless you patch again Qt to look in
non-standard locations.".

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