Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[René J . V . Bertin]

Thiago Macieira wrote:

> On sexta-feira, 24 de junho de 2016 18:12:25 PDT René J.  V. Bertin wrote:
>> The remark above did make me wonder if QtDBus couldn't use a
>> platform-native  backend transparently. It seems unlikely (just as you
>> probably cannot replace dbus itself by something that isn't ... dbus) but
>> it cannot hurt to ask :)
 
> What do you mean by that? What is a "platform-native backend"? 

Something that uses the platform's native desktop bus, as far as something like 
that exists.

> How would it be used transparently?

If 2 applications communicate via QtDBus calls it doesn't really matter what 
QtDBus does, it hides the implementation details. Instead of a daemon there 
could be an angel that handles the communication ;)

> And more importantly, what is any of that different than
> what QtDBus does right now?

Well, that's the main point, isn't it. Replacing dbus by something that does 
the 
same thing almost the same way only in order to avoid using dbus doesn't make a 
lot of sense.

I wasn't wondering aloud how we could do something completely different, but 
rather what could be improved to make dbus a true cross-platform daemon-based 
desktop bus service that cannot be accused of being a fish out of the water.

R

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[Thiago Macieira]

On sexta-feira, 24 de junho de 2016 18:12:25 PDT René J.  V. Bertin wrote:
> The remark above did make me wonder if QtDBus couldn't use a
> platform-native  backend transparently. It seems unlikely (just as you
> probably cannot replace dbus itself by something that isn't ... dbus) but
> it cannot hurt to ask :)

What do you mean by that? What is a "platform-native backend"? How would it be 
used transparently? And more importantly, what is any of that different than 
what QtDBus does right now?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[René J . V . Bertin]

Shawn Rutledge wrote:

> I thought he meant to add it as a cross-platform feature, not leave it in the
> extras modules.

Ah, yes, that would be a possibility if the feature can be implemented in such 
a 
way that a platform-agnostic API makes sense. Which it should, there really 
isn't that much to control in a simple progressbar widget :)

> 
> Static in QProgressBar only makes sense if one application can only have one
> icon.  But why not have this feature available on each minimized window, in
> case multiple windows are busy?  (Well, some docks collapse multiple windows
> into one icon anyway.) 

I am not aware that this would make sense on OS X. You have the choice whether 
minimised windows are shown individually or not, but even if they are I don't 
think you can even access their icons (tiles). I've never tried though.

> loaded.  When we implement D-Bus protocols in our platform plugins, we do that
> with QtDBus, not by linking other libraries.  In that case, we are obliged to

To take this a bit further away from the original topic: I have seen multiple 
remarks off late about how DBus is a "fish out of the water" everywhere else 
but 
on FreeDesktop-based systems. While it's true that DBus isn't a "native" 
service 
on those platforms there's a clear intention for it to work and integrate 
properly (without 3rd party patches) at least on OS X and MS Windows. 
Personally 
I thus consider it a cross-platform desktop bus implementation.
The remark above did make me wonder if QtDBus couldn't use a platform-native 
backend transparently. It seems unlikely (just as you probably cannot replace 
dbus itself by something that isn't ... dbus) but it cannot hurt to ask :)


> The same story will probably repeat in the context of system notifications,

KF5's KNotifications? 

R.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[Shawn Rutledge]

> On 24 Jun 2016, at 11:19, René J. V. Bertin  wrote:
> 
> Mike Krus wrote:
> 
>> 
>>> On 22 Jun 2016, at 11:17, Kevin Funk  wrote:
>>> A platform agnostic wrapper for all this would be indeed great to have!
>> If QtWinExtra has it, QtMacExtra can have it, and it’s doable on Linux, why
>> not add static methods on QProgressBar?
> 
> Why would you add Linux-only methods to QProgressBar? It would make more 
> sense 
> to add something to QtX11Extras if there's a sensible way to do this under 
> X11. 
> Otherwise you'd be adding to QtKDEExtras, oops, that's called KF5 :)

I thought he meant to add it as a cross-platform feature, not leave it in the 
extras modules.

Static in QProgressBar only makes sense if one application can only have one 
icon.  But why not have this feature available on each minimized window, in 
case multiple windows are busy?  (Well, some docks collapse multiple windows 
into one icon anyway.)  But then the API needs more thought; maybe we can do 
better than clutter up the API of QWindow or QProgressBar or QGuiApplication.  
And BTW QtQuick Controls 2 is adding support for native menus, tray icons and 
such, so it would make sense to have QML API for this feature too, I suppose.

On Unity the D-Bus protocol is apparently this

https://wiki.ubuntu.com/Unity/LauncherAPI

and apparently work in progress on KDE:

https://git.reviewboard.kde.org/r/127050/

but we haven’t implemented any part of that protocol in Qt, yet.  It could be 
done.

There is an annoying warning which got mentioned on that KDE page:

"While the libunity API is stable, the DBus protocol underneath is not. We 
strongly discourage anyone from relying on it"

Philosophically I think that’s wrong.  (But it’s not the first time I’ve seen 
that attitude.)  A D-Bus protocol is a specification (just like say, a WiFi or 
Bluetooth specification, or any network RFC): revisions should be few and far 
between, while implementations naturally tend to be more numerous, and need 
more frequent fixes.  We really expect the authors of such things to think them 
through before the D-Bus protocol has “final specification” status.  And we 
don’t want to depend on yet another library, especially one which will not 
exist except on an Ubuntu system, and would therefore need to be dynamically 
loaded.  When we implement D-Bus protocols in our platform plugins, we do that 
with QtDBus, not by linking other libraries.  In that case, we are obliged to 
ignore any warnings about the protocol being unstable (or else allow the 
warning to dissuade us from doing anything at all).  So whether Canonical or 
Gnome likes it or not, every time they change a protocol which we’ve 
implemented, our implementation will lag behind.  They had better do any 
protocol changes in backwards-compatible ways.  Anything else is unrealistic, 
IMO.  Isn’t it the same issue for KDE implementing those?  Maybe we should 
treat KDE interest in implementing a Unity protocol as a sign that the 
specification can be considered frozen, and the warning is moot.

The tendency for third parties to make adjunct Qt plugins (such as style 
plugins) to add such features, like KDE and Unity have been doing, also has 
side effects: the feature is not portable.  When they bundle behavior changes 
and styling changes together, those plugins are left behind when users build or 
install new versions of Qt on their own: the plugin is only for the minor 
version of Qt that it was built for.  And then users wonder why the nifty 
features that those plugins added don’t work anymore.  This is why we 
independently added support for the D-Bus tray icons, their menus, and the 
unified menubar: those features began to be widely available on multiple 
desktops, and thus expected, regardless of Qt version.  It’s not a great use of 
time though, that different people implemented the same features in different 
ways.  It would be better if people would contribute patches for such things to 
Qt in the first place.  But for new features, hammering out proper API is 
important work, and takes time and patience.

It seems like the progress bar could be a cross-platform feature.  So we just 
need to think up a sufficiently general API that doesn’t look like it will be 
too limiting later, if the feature is expanded in some way.

The same story will probably repeat in the context of system notifications, 
BTW, and we’ll see what else.  There is work in progress on a pluggable 
notification system.  In general, these interfaces to the rest of the desktop 
(which use D-Bus on Linux) are slowly proliferating.  In another thread we are 
discussing how to handle communications and data sharing between apps on mobile 
platforms.  My hunch is that the good ideas from there will tend to end up 
being D-Bus specifications on desktop Linux, too, to bring them cross-platform 
instead of only on mobile devices.

___
Development mailing 

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[René J . V . Bertin]

Mike Krus wrote:

> 
>> On 22 Jun 2016, at 11:17, Kevin Funk  wrote:
>> A platform agnostic wrapper for all this would be indeed great to have!
> If QtWinExtra has it, QtMacExtra can have it, and it’s doable on Linux, why
> not add static methods on QProgressBar?

Why would you add Linux-only methods to QProgressBar? It would make more sense 
to add something to QtX11Extras if there's a sensible way to do this under X11. 
Otherwise you'd be adding to QtKDEExtras, oops, that's called KF5 :)

R.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[Mike Krus]

> On 22 Jun 2016, at 11:17, Kevin Funk  wrote:
> A platform agnostic wrapper for all this would be indeed great to have!
If QtWinExtra has it, QtMacExtra can have it, and it’s doable on Linux, why not 
add
static methods on QProgressBar?


Mike

--
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK +44-1625-809908   Mobile: +44 7833 491941
KDAB - The Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[René J . V . Bertin]

On Wednesday June 22 2016 11:50:04 Marc Mutz wrote:

>It probably makes sense to add a couple of slots to QSystemTrayIcon (is there 
>something similar in GUI?).

Except that the tray icon isn't related to the Dock icon on OS X ... It shows 
up in the menubar and is much too small to add a sensible progressbar to it.

>Windows also has taskbar progress. Not sure about KDE/Linux.
On Wednesday June 22 2016 10:08:03 Eike Ziller wrote:
>Nobody of us found a sensible way to do something similar on various Linux 
>desktops though.

As Kevin said, there's something in Unity that could be used (cf 
https://git.reviewboard.kde.org/r/127050), but closer to home you can also find 
a progressbar via the KNotifications systray icon/menu. At least there's one in 
KDE4 showing the progress of certain file copy operations. Whether it's useful 
to have such a display in a GUI element that you have to expose explicitly is a 
bit of a question; if the application providing the progress info has a 
progressbar of its own (like Creator) you could just as well expose or switch 
to that application.

>Qt Creator has an implementation for windows too
>http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/coreplugin/progressmanager/progressmanager_win.cpp

Yeah, but without a proper MSWin dev rig I'm not going to propose anything to 
provide it via an upstream patch/class ;)

R.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[Kevin Funk]

On Mittwoch, 22. Juni 2016 10:08:03 CEST Eike Ziller wrote:
> > On Jun 22, 2016, at 11:50 AM, Marc Mutz  wrote:
> > 
> > On Tuesday 21 June 2016 12:36:02 René J.V. Bertin wrote:
> >> On Tuesday June 21 2016 09:50:52 Eike Ziller wrote:
> >>> I think this would be more a question to the Qt/macOS developers, to be
> >>> asked on the development@ mailing list ;)
> >> 
> >> OK then :)
> >> 
> >> I've, erm, borrowed some code from Qt Creator to add a Dock icon
> >> progressbar to KDevelop, adding a minimal API (only static methods as an
> >> app has only a single Dock icon) as well as a poor man's indeterminate
> >> mode. The code is still under review
> >> (https://git.reviewboard.kde.org/r/128188) so I wonder if I shouldn't
> >> instead by proposing it as a QtMacExtras addition.
> >> 
> >> What do you think? Any suggestions how to integrate this into
> >> QtMacExtras,
> >> as a standalone class or as additional QtMac methods?
> > 
> > Windows also has taskbar progress. Not sure about KDE/Linux.
> 
> Qt Creator has an implementation for windows too
> http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/coreplugin
> /progressmanager/progressmanager_win.cpp
> 
> Nobody of us found a sensible way to do something similar on various Linux
> desktops though.

The closest thing on Linux is probably the Unity Launcher API. I only know it 
because Plasma started to support it (read: use it) in Plasma 5.6.

More information here:
  http://blog.broulik.de/2016/01/on-being-more-convenient/
  https://wiki.ubuntu.com/Unity/LauncherAPI

A platform agnostic wrapper for all this would be indeed great to have!

Cheers,
Kevin

> 
> Br, Eike
> 
> > It probably makes sense to add a couple of slots to QSystemTrayIcon (is
> > there something similar in GUI?).
> > 
> > Thanks,
> > Mard


-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[Eike Ziller]

> On Jun 22, 2016, at 11:50 AM, Marc Mutz  wrote:
> 
> On Tuesday 21 June 2016 12:36:02 René J.V. Bertin wrote:
>> On Tuesday June 21 2016 09:50:52 Eike Ziller wrote:
>>> I think this would be more a question to the Qt/macOS developers, to be
>>> asked on the development@ mailing list ;)
>> 
>> OK then :)
>> 
>> I've, erm, borrowed some code from Qt Creator to add a Dock icon
>> progressbar to KDevelop, adding a minimal API (only static methods as an
>> app has only a single Dock icon) as well as a poor man's indeterminate
>> mode. The code is still under review
>> (https://git.reviewboard.kde.org/r/128188) so I wonder if I shouldn't
>> instead by proposing it as a QtMacExtras addition.
>> 
>> What do you think? Any suggestions how to integrate this into QtMacExtras,
>> as a standalone class or as additional QtMac methods?
> 
> Windows also has taskbar progress. Not sure about KDE/Linux.

Qt Creator has an implementation for windows too
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/coreplugin/progressmanager/progressmanager_win.cpp

Nobody of us found a sensible way to do something similar on various Linux 
desktops though.

Br, Eike

> It probably makes sense to add a couple of slots to QSystemTrayIcon (is there 
> something similar in GUI?).
> 
> Thanks,
> Mard
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> ___
> Qt-creator mailing list
> qt-crea...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
+123 45 6789012
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [OS X] Dock icon progress widget

[Marc Mutz]

On Tuesday 21 June 2016 12:36:02 René J.V. Bertin wrote:
> On Tuesday June 21 2016 09:50:52 Eike Ziller wrote:
> >I think this would be more a question to the Qt/macOS developers, to be
> >asked on the development@ mailing list ;)
> 
> OK then :)
> 
> I've, erm, borrowed some code from Qt Creator to add a Dock icon
> progressbar to KDevelop, adding a minimal API (only static methods as an
> app has only a single Dock icon) as well as a poor man's indeterminate
> mode. The code is still under review
> (https://git.reviewboard.kde.org/r/128188) so I wonder if I shouldn't
> instead by proposing it as a QtMacExtras addition.
> 
> What do you think? Any suggestions how to integrate this into QtMacExtras,
> as a standalone class or as additional QtMac methods?

Windows also has taskbar progress. Not sure about KDE/Linux.

It probably makes sense to add a couple of slots to QSystemTrayIcon (is there 
something similar in GUI?).

Thanks,
Mard

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development