On 27/10/11 15:29, Aaron J. Seigo wrote:
On Thursday, October 27, 2011 14:24:26 Craig Drummond wrote:
1. TaskAction changes - these are self contained anyway.
2. Launcher matching - mainly TaskItem::launcherUrl() changes.
3. Launcher ordering - basically everything else.
Would that be enough?
On Friday, October 28, 2011 23:40:03 Jan Gerrit José Marker wrote:
That would prevent from bloating the code and would make the matching more
flexible.
while this would work, given the amount of corner cases that need covering and
their complexity, this would be an over-engineered solution. if
Original-Nachricht
Datum: Fri, 28 Oct 2011 00:35:46 +0100
Von: David Edmundson da...@davidedmundson.co.uk
An: plasma-devel@kde.org
Betreff: Re: IconTasks taskmanager changes
In KDE Telepathy we have several dbus-activated apps that
1) Do not have .desktop files
2) Should
it cannot be run two times. The check for an already running Amarok
should
happen just in Amarok itself...
And here with the unpatched libtaskmanager and the standard
task-widget
exactly what you propose happens.
Ok, bad example. Think of any non-KUniqueApp in systray then,
On Friday, October 28, 2011 09:47:50 Craig Drummond wrote:
The problem here is that the taskmanager library does not really manage
tasks, but windows. So, when Quassel is minimised to the system try, the
taskamanger emits a windowRemoved - and the task applets remove the entry.
The launcher is
On Fri, Oct 28, 2011 at 09:47, Craig Drummond craig.drumm...@gmx.netwrote:
it cannot be run two times. The check for an already running Amarok
should
happen just in Amarok itself...
And here with the unpatched libtaskmanager and the standard
task-widget
exactly what you
On Thursday 27 October 2011 14:10:50 Craig Drummond wrote:
[snip]
No, just to now allow it. And for the user to be prompted to locate the
launcher.
I cant imagine many people pinning kcm's.
yes, it's an edge case for certain. would be nice if it works, all the
same.
But, is it worth
On Wednesday, October 26, 2011 17:24:08 Craig Drummond wrote:
On 26/10/11 15:59, Aaron J. Seigo wrote:
On Wednesday, October 26, 2011 15:13:02 Craig Drummond wrote:
Then you simply cannot pin the application to the taskbar. Is that such a
big deal?
it would be a regression with no
The only
cases where IconTasks will not create a launcher, where current taskbar
may, is when no desktop file is present. But I dont see this as that big
a deal.
.. and that is the regression. you can't start with it isn't a
regression
and then end with it regresses the current
On Thursday, October 27, 2011 13:16:25 Craig Drummond wrote:
The only
cases where IconTasks will not create a launcher, where current taskbar
may, is when no desktop file is present. But I dont see this as that big
a deal.
.. and that is the regression. you can't start with it
IconTasks *already* does this. It doesn't use libprocesscore, as I was
not
aware of this - it reads /proc, so this probably needs
updating/fixing.
indeed, as that is not very portable.
I've just started looking at libprocesscore. However, there seems to be no
quick way of getting the
first: thanks for providing the patch. this is the good news :)
the bad news: it's unreviewable. 2639 lines covering 30 files all in one
text
file .. too cumbersome.
Well you can look at it with kompare :-)
what do you think?
I think this sounds good, just my git skills are practically
On Thursday, October 27, 2011 14:10:50 Craig Drummond wrote:
yes, it's an edge case for certain. would be nice if it works, all the
same.
But, is it worth adding work-arounds for such an edge case? Why bloat the
code with something that is unlikely to occur? At least I dont see it as a
On Thu, Oct 27, 2011 at 2:29 PM, Aaron J. Seigo ase...@kde.org wrote:
On Thursday, October 27, 2011 14:10:50 Craig Drummond wrote:
yes, it's an edge case for certain. would be nice if it works, all the
same.
But, is it worth adding work-arounds for such an edge case? Why bloat the
code
On Thursday, October 27, 2011 14:44:17 todd rme wrote:
This may be an ignorant question, but what is wrong with using the
existing application picker dialog as-is? As best as I can tell it
nothing. the question isn't whether or not to use the application picker
dialog (we all seem to agree it
On Thursday, October 27, 2011 14:24:26 Craig Drummond wrote:
1. TaskAction changes - these are self contained anyway.
2. Launcher matching - mainly TaskItem::launcherUrl() changes.
3. Launcher ordering - basically everything else.
Would that be enough?
sure :)
it would be very good to see
On Wednesday 26 October 2011 21:22:31 Craig Drummond wrote:
I don't think that the normal user will be able to find the desktop file
manually in the filesystem. The experienced user can still add the
desktop-file easily per dragdrop (provided the applet supports it).
That said, I must
On Thursday 27 October 2011 16:21:28 Aaron J. Seigo wrote:
On Thursday, October 27, 2011 14:44:17 todd rme wrote:
This may be an ignorant question, but what is wrong with using the
existing application picker dialog as-is? As best as I can tell it
nothing. the question isn't whether or not
On Oct 27, 2011 10:12 PM, Craig Drummond craig.drumm...@gmx.net wrote:
On 27/10/11 18:32, Anton Kreuzkamp wrote:
On Thursday 27 October 2011 16:21:28 Aaron J. Seigo wrote:
On Thursday, October 27, 2011 14:44:17 todd rme wrote:
This may be an ignorant question, but what is wrong with using
On Thursday 27 October 2011 23:11:13 Martin Klapetek wrote:
On Oct 27, 2011 10:12 PM, Craig Drummond craig.drumm...@gmx.net wrote:
On 27/10/11 18:32, Anton Kreuzkamp wrote:
On Thursday 27 October 2011 16:21:28 Aaron J. Seigo wrote:
On Thursday, October 27, 2011 14:44:17 todd rme wrote:
On Thursday 27 October 2011 21:05:09 Craig Drummond wrote:
On 27/10/11 18:08, Anton Kreuzkamp wrote:
On Wednesday 26 October 2011 21:22:31 Craig Drummond wrote:
The user is prompted with a dialog showing the list of installed apps -
this is basically a copy of the Open With dialog. The user
On 27/10/11 22:36, Anton Kreuzkamp wrote:
On Thursday 27 October 2011 21:05:09 Craig Drummond wrote:
On 27/10/11 18:08, Anton Kreuzkamp wrote:
On Wednesday 26 October 2011 21:22:31 Craig Drummond wrote:
The user is prompted with a dialog showing the list of installed apps -
this is basically
On Oct 27, 2011 11:35 PM, Anton Kreuzkamp akreuzk...@web.de wrote:
On Thursday 27 October 2011 23:11:13 Martin Klapetek wrote:
snip
Little bit sidetrack - I've been using Icon Tasks for quite some time
now
and it's really cool. As for the launchers - would it be possible to
detect
if
On Thursday 27 October 2011 22:42:39 Craig Drummond wrote:
On 27/10/11 22:36, Anton Kreuzkamp wrote:
On Thursday 27 October 2011 21:05:09 Craig Drummond wrote:
On 27/10/11 18:08, Anton Kreuzkamp wrote:
On Wednesday 26 October 2011 21:22:31 Craig Drummond wrote:
The user is prompted with a
On Friday 28 October 2011 00:00:02 Martin Klapetek wrote:
On Oct 27, 2011 11:35 PM, Anton Kreuzkamp akreuzk...@web.de wrote:
On Thursday 27 October 2011 23:11:13 Martin Klapetek wrote:
snip
Little bit sidetrack - I've been using Icon Tasks for quite some time
now
and it's really
In KDE Telepathy we have several dbus-activated apps that
1) Do not have .desktop files
2) Should not be able to be pinned to the taskbar
These apps are launched by telepathy and never by the user. The best
example is the chat application (telepathy-kde-text-ui) which is the
app used for a text
For the last couple of months I've been working on an icon-only task bar called
IconTasks. (I've just uploaded the latest, 0.8.1, to kde-look -
http://kde-look.org/content/show.php/Icon+Tasks?content=144808)
This contains a forked version of taskmanager, which I would like to fold back
into
Am 26.10.2011 13:30, schrieb Craig Drummond:
For the last couple of months I've been working on an icon-only task
bar called IconTasks. (I've just uploaded the latest, 0.8.1, to
kde-look -
http://kde-look.org/content/show.php/Icon+Tasks?content=144808)
This contains a forked version of
On Wednesday, October 26, 2011 13:30:56 Craig Drummond wrote:
This contains a forked version of taskmanager, which I would like to fold
back into the main taskmanager code. Seeing as soft feature freeze is on
the 27th (tomorrow!), I thought I should ask if it is ok to add this to the
feature
I think it's great that you want to bring back your changes :-) And
given the positive feedback I have heard for your tasks implementation I
would like to see this in 4.8, so yes please add it to the feature
plan.
OK, I'll add both to the feature plan later. But the library changes would
you can add it to the feature list, however importing IconTasks itself to
kdeplasma-addons means that all things are merged. so i'd like that to be
a
(very) soft target and concentrate first on the patches ot libtaskmanager.
Yup, thats what I'd do. I'd rather have the taskmanager changes
On 26/10/11 15:59, Aaron J. Seigo wrote:
On Wednesday, October 26, 2011 15:13:02 Craig Drummond wrote:
Then you simply cannot pin the application to the taskbar. Is that such a
big deal?
it would be a regression with no justifiable argument for why it should
regress.
a good exercise is to
Attached is diff of IconTask's 0.8.2 taskmanager against the current
taskmanager in master.
The main changes are...
abstractgroupingstrategy.cpp
a. When a group is created, it is placed at the same index as the first
member. Likewise when a group is removed, the last remaining member (if
On Wednesday 26 October 2011 17:24:08 Craig Drummond wrote:
On 26/10/11 15:59, Aaron J. Seigo wrote:
On Wednesday, October 26, 2011 15:13:02 Craig Drummond wrote:
Then you simply cannot pin the application to the taskbar. Is that such a
big deal?
it would be a regression with no
I don't think that the normal user will be able to find the desktop file
manually in the filesystem. The experienced user can still add the desktop-file
easily per dragdrop (provided the applet supports it).
That said, I must admit that the creating the launcher without desktop-file
doesn't
35 matches
Mail list logo
