ures and possibly release new major versions in
> case the API turns out to not be flexible enough.
>
> You can find the repository here:
> https://invent.kde.org/libraries/futuresql.
> Please let me know the issues you find here or on GitLab
> (https://invent.kde.org/libraries/
ub.com/steveire/
> grantlee/pulls <https://github.com/steveire/grantlee/pulls>. Also are
> there some open issues which might be wanted to be
> moved over to bugs.kde.org?
>
> Cheers
> Friedrich
>
>
>
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
previous developer hasn't
> responded to me. The projects irc channel and sites are dead, too.
>
> I was hoping someone here might be able to help me on this.
>
> Lasse Lindqvist
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
ng a grab from a sidearm process. In doubt, the only possible
> hardening would be to continuously - and the only test whether it worked
> would be to invoke QWindow::setMouseGrabEnabled(bool grab) as well.
>
> Stay tuned ;-)
>
> Cheers,
> Thomas
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
relying on PackageKit
> which means it can act as a frontend to different technologies other than
> packagekit, currently bodega, KNS/OCS and Apt (the last one for historic and
> practical reasons).
Support for different technologies could also be added to Apper but no
one ever stepped up to giv
+Martin,
does clicking on the shadow drawn by the window
also prevents you from say focusing the window
below (when no windeco is in place)? As from what
I understood there is no hint margins.
Maybe add this to your big list :P
re other suggestions on how to make trabslating AppData files
> easier for KDE?
Well the .desktop files have the translations inside it, I think the
same could be applied to AppData.
Best,
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
support
AppData and AppStream it is just sad as
Apper will end up listing only GNOME apps
as applications...
Best,
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
with a sniper rifle
> d) at some point port to phonon5
> e) more of c
>
> Phonon backends are incredibly low maintenance if written well, except
> that Phonon GStreamer is not written well (at least in my opinion, and
> I am very opinionated about what good code looks like, so I may be
> wrong). Above steps are by the way what I did with Phonon VLC so I'll
> call it the 'apachelogger method'(tm) and assert it as the only way to
> make a phonon backend not suck donkey balls.
>
> [1] http://community.kde.org/Phonon/FeatureMatrix
>
> HS
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
uess that's what Lamarque thought.
>
>
> OK, so back to revision 1 in that case.
>
>
> Cheers,
> Eike
>
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
would in no way consider this a bug fix.
>
> --
> Martin Sandsmark
>
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
hough, if an app wishes to use Oyranos directly as a hard
>> requirement because of some better functionality or less code then they
>> are
>> free to do so, but it does come at a cost that they need to be aware of, a
>> cost which I don't think belongs in kdelibs or Workspace.
>
> Hmm, reads like a plan to abstract from the Oyranos abstraction API. Maybe a
> graphics scheme could help in making that idea better understandable?
IMO if you could turn your Oyranos libs into a simple library and make
it into kdelibs
which didn't had hard deps with Oyranos or colord (only linked abaings
Qt/KDE and
lcms2), would be what Krita & friends would need...
Best,
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
Can't you move the code to a different thread?
Em 03/01/2013 20:03, "Cédric Bellegarde" escreveu:
> Le jeudi 3 janvier 2013 18:09:25 David Edmundson a écrit :
> > Always use async calls for everything
>
> On kded-appmenu part, the blocking code isn't in kded-module but in
> appmenu-qt
> plugin u
It's a known issue, we ha random code running on the same thread.. A work
around is to put the code on a thread, and make sure all your call are non
blocking.
I'm planing on doing a prof of concept to change the way kded works to have
this and other problems gone.
Best
Em 03/01/2013 14:14, "Ced
l the bug number
on bko but might be that...
Best,
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
2012/11/1 Lamarque V. Souza :
> What kind of things should go to extragear/base then?
>
>
>
> networkmanagement is four things: a plasmoid, a kded module, a kcmshell
> module and a standalone application for adding new connections. I think the
> retionale for networkmanagement be in extrager/base i
Hmm dont you think network is a better place? I think base would be the
last place Id look for
Em 01/11/2012 19:48, "Lamarque V. Souza" escreveu:
> **
>
> Em Thursday 01 November 2012, Christoph Feck escreveu:
>
> > On Thursday 01 November 2012 22:19:03 Lamarque V. Souza wrote:
>
> > > Em Thursda
2012/9/17 Albert Astals Cid :
> Can you please also take care of moving/unmaintaining the two apps it
> replaces?
sure, will do.
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
ternal lib, maybe
> kde workspace would be a good place to stay.
Hi, it's been two weeks since it entered KDE review,
I hope all translations issues were fixed, and would like to know
where should I move it, and how do we proceed now since
it seems no one has objected the replacement
2012/8/27 Thomas Lübking :
> Am 27.08.2012, 22:53 Uhr, schrieb Daniel Nicoletti :
>
>
>> So to avoid the application quiting modules that need to perform
>> async tasks like talking to polkit or installing packages (Apper),
>> they need to create an event loop so
2012/8/27 Christoph Feck :
> On Monday 27 August 2012 22:15:18 Daniel Nicoletti wrote:
>> 2012/8/27 Christoph Feck :
>> > I am talking about whatever design mistake is responsible for bug
>> > 242648, which isn't about CUPS at all. Sorry for side-tracking
>> &
2012/8/27 Christoph Feck :
> On Sunday 26 August 2012 06:34:30 Daniel Nicoletti wrote:
>> 2012/8/25 Christoph Feck :
>> > On Saturday 25 August 2012 04:29:19 Daniel Nicoletti wrote:
>> >> 2012/8/23 Christoph Feck :
>> >> > On Wednesday 22 August 201
2012/8/25 Christoph Feck :
> On Saturday 25 August 2012 04:29:19 Daniel Nicoletti wrote:
>> 2012/8/23 Christoph Feck :
>> > On Wednesday 22 August 2012 21:39:11 Daniel Nicoletti wrote:
>> Well CUPS has it's own API for authorization, which is why I
>> avoided
Sorry forgot to reply to all..
2012/8/23 Christoph Feck :
> On Wednesday 22 August 2012 21:39:11 Daniel Nicoletti wrote:
>> two years ago I started print-manager, at that time
>> I was using Debian which is affected by this bug:
>> https://bugs.kde.org/show_bug.cgi?id=2719
2012/8/24 Burkhard Lück :
> Am Donnerstag, 23. August 2012 16:49:08 schrieb Daniel Nicoletti:
>> Sorry I always have problems with these things,
>> I've just copied the messages.sh from my other
>> project Apper, then Kai Uwe b did some changes
>> on it but mayb
st 2012 21:39:11 schrieb Daniel Nicoletti:
>> Right now translations are mostly undone which is
>> why I feel important to do the move as soon as possible
>> so KDE 4.10 has it well translated.
>
> Seems there is something wrong with the message extraction in print-manager,
&
layground/base/print-manager
but a sysadmin request to move has already been filled
Best,
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
> On June 21, 2012, 10:05 p.m., Mark Gaiser wrote:
> > I don't really know if we should do this.. I do understand why you want to
> > rename it. From a user point of view the user probably wants to either
> > access windows shares or make shares accessible for windows. Either way,
> > it's don
Hi,
it's been 15 days since I've asked for
the review, and we have fixed all the issues so far,
should I ask kdesysadmin for the move now?
Thanks,
Daniel.
Extragear, as I depend on PackageKit releases
this would be more flexible for me :)
Best,
2012/5/22 Anne-Marie Mahfouf :
> On 05/21/2012 11:31 PM, Daniel Nicoletti wrote:
>>
>> Hi,
>> Apper is on playground probably since 2008,
>> it's widely used nowadays so it
Hi,
Apper is on playground probably since 2008,
it's widely used nowadays so it doesn't make
sense to keep it there anymore.
So please review the code, make suggestions and such...
Right now the code is at (I've asked kde sysadmin to move to
kdereview, but afaik it will only reflect the projects
2012/3/22 Sune Vuorela :
> On 2012-03-22, Daniel Nicoletti wrote:
>> people draw API they have this in mind and we don't need a whole new Qt just
>> to
>> introduce a new feature, easy solution:
>> QApplication::setColorCorrected(true);
>
> Th
2012/3/22 Kai-Uwe Behrmann :
> Here my thoughts, why I think CM in Qt is not easily introduced during a
> minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.]
>
> Lets hypothetical assume some effort is initiated to bring CM to Qt and that
> happens during Qt 5 life time. The new
2012/3/15 Kai-Uwe Behrmann :
> ... and do caching, lookup, perhaps wrapping of CMMs and so one. Would it
> not be nice to share that?
Really caching of so small files? If you cache small files you have an unneeded
overhead at best and a complex solution at worst.
> That is a apple against orange p
> So far colour conversion happens on the end machine. That is the one,
> which is connected to the device. That fits to what Michael Sweet says about
> early versus late colour binding, suggesting that early colour binding can
> cause
> gigabytes of traffic, while late colour bind will have no
> On the other hand if there are things that a mere 'power user' might
> find
> useful (that colord will not be supporting due to scope) then it might make
> sense to have extra U/I if Oyranos is available. Perhaps multi-monitor CMS
> would fit the bill (assuming colord will not support).
I'm
>Like I also help with Wicd support in KDE, Kopete, and other areas of
>interests for KDE users. I do not use Wicd, but I help KDE users of Wicd even
>before I was the Network Management maintainer. By the way, I am not driven by
>FDO interests. We are using upower/udisks because there is no oth
>Oyranos were against the patch, Kai-Uwe already said that and explained why.
>The fact that
>there is patch does not mean it is the correct way to do things. The fact that
>it is not integrated
>upstream can also mean cups developers to do not like it. Do you know what
>they think about the pa
> So you are saying your original argument is not valid anymore?
Where is the Oyranos CUPS patch? All I see is a planning since as
far as I can tell he didn't decide the best way to do it, OTOH we have
something that already works for a bunch of people.
> I said I wanted the most versatile, which
>As long as you patch cups and all other applications to use. Oyranos is also a
>central place
> to do color management as far as I know, this argument is valid for both.
It is valid once it's written, once there is a line of code doing it's job. Or
we can just play politics.
You say you want t
> 2012/3/14 Kai-Uwe Behrmann :
> CUPS is a cross platform solution. It works with colour management on osX
> fine. IMO that recommendation on Debian has to do with colord in Gnome and
> that colord needs compiled in support inside CUPS. No more no less.
This sentence is hard to read but Recommends
2012/3/14 Kai-Uwe Behrmann :
> CUPS is a cross platform solution. It works with colour management on osX
> fine. IMO that recommendation on Debian has to do with colord in Gnome and
> that colord needs compiled in support inside CUPS. No more no less.
This sentence is hard to read but Recommends i
> I know basically nothing about color management systems.
> Don't some applications needs some kind of interface to use the color
> management system ?
> Or is it only for setting up X, the printer, Wayland, etc.
>
> In the first case, if applications (e.g. krita) need some way to work with the
>
I don't think so, I think it has some huge icons but I thought
it was my browsers problem, the huge header and footer
it's real hard to see the content on my small screen,
the new version fews snappier but the theme needs polishing
imo. I also renders the footer strange using Chrome,
but I hope som
> I know basically nothing about color management systems.
> Don't some applications needs some kind of interface to use the color
> management system ?
> Or is it only for setting up X, the printer, Wayland, etc.
>
> In the first case, if applications (e.g. krita) need some way to work with the
>
> The wiki page somebody pointed to mentioned that colord is linux-only, while
> oyranos also works on Windows and OSX.
>
> If we chose colord, how does our solution for Windows and OSX look like ?
> Does kolormanager work under Windows and OSX ?
> The wiki page somebody pointed to mentioned tha
>> I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and
>>I am
>> pretty much just rewriting it with Qt/KDE libs.
>
> OpenICC colour experts have then a different view of maturity.
>
>>
> 1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
>
> No. There should be color management by default in KDE, that's really
> important; and there should be only one solution by default. We shouldn't
> let distributions, or even worse, users decide which solution they use. That
> way
> madness lies. KDE's Color management solution shouldn't be
xtragear or is there some different policy in this case?
I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I am
pretty much just rewriting it with Qt/KDE libs.
1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
Best,
Daniel Nicoletti
ny other way of doing this)
Anyways I don't intend to increase the flames here just to point out
that I'm going to start on this, I don't have much time so if some new comers
are wiling for a from scratch job be welcome :D
Daniel Nicoletti - KDE De
50 matches
Mail list logo
