On Monday, October 31, 2011 20:49:13 Craig Drummond wrote:
> 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.
>
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
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,
On Fri, Oct 28, 2011 at 09:47, Craig Drummond wrote:
>
> > > > 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
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
> > > 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
Original-Nachricht
> Datum: Fri, 28 Oct 2011 00:35:46 +0100
> Von: David Edmundson
> 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) Sho
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 ch
On Friday 28 October 2011 00:00:02 Martin Klapetek wrote:
> On Oct 27, 2011 11:35 PM, "Anton Kreuzkamp" wrote:
> > On Thursday 27 October 2011 23:11:13 Martin Klapetek wrote:
>
>
> > > Little bit sidetrack - I've been using Icon Tasks for quite some time
>
> now
>
> > > and it's really cool. A
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 p
On Oct 27, 2011 11:35 PM, "Anton Kreuzkamp" wrote:
>
> On Thursday 27 October 2011 23:11:13 Martin Klapetek wrote:
> >
> > 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 the app is
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 a
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
On Thursday 27 October 2011 23:11:13 Martin Klapetek wrote:
> On Oct 27, 2011 10:12 PM, "Craig Drummond" 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
On Oct 27, 2011 10:12 PM, "Craig Drummond" 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 t
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 the
existing application picker dialog as-is? As best as I can tell it
noth
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 does not
need to manually find it in the filesystem.
Craig.
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
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 drag&drop (provided the applet supports it).
> > That said, I m
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
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 Thu, Oct 27, 2011 at 2:29 PM, Aaron J. Seigo 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 with
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
> 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 practi
> > 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 gett
On Wednesday, October 26, 2011 20:57:32 Craig Drummond wrote:
> Attached is diff of IconTask's 0.8.2 taskmanager against the current
> taskmanager in master.
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 te
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 st
> > 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
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
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 drag&drop (provided the applet supports it).
That said, I must admit that the creating the launcher without desktop-file
doesn't wor
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 wi
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
any)
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 imag
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 imagine explaining it to a user why that on
> 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 change
> 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 wou
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
> featur
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 taskmanag
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 the
40 matches
Mail list logo
