Re: KDE backward compatibility issue
On Fri, Jan 30, 2015 at 6:40 PM, Thomas Lübking wrote: > On Freitag, 30. Januar 2015 18:22:03 CEST, Vasily Khoruzhick wrote: > >> It's a way to keep all tray icons on the panel. In case of horizontal >> panel >> it's even seemless > > > I'd not rather not expect a "seamless" result from this approach. > You'll have an autopositioned/hiding wmsystemtray though, that's true. And you wouldn't have to worry about window management. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Use of Air wallpaper by Sony
I am not sure the proper place for this. A user on the KDE Forum brought it to our attention that Sony is using the Air wallpaper for production photos on their laptops. See here: http://www.dabs.com/products/sony-vaio-e-series-eb3j0e-wi-core-i3-370m-2-4ghz-4gb-320gb-15-5--windows-7-home-premium-64bit-laptop-766T.html I am not sure what the license is on the wallpaper, or if Sony got proper permission, or if anyone even cares (or might even like it), but I thought I should bring it to your attention just in case there is something that should be done about it. Original forum thread: http://forum.kde.org/viewtopic.php?f=15&t=91306 -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Use of Air wallpaper by Sony
On Mon, Nov 8, 2010 at 8:13 PM, Michael Pyne wrote: > On Monday, November 08, 2010 11:17:49 todd rme wrote: >> I am not sure the proper place for this. A user on the KDE Forum >> brought it to our attention that Sony is using the Air wallpaper for >> production photos on their laptops. See here: >> >> http://www.dabs.com/products/sony-vaio-e-series-eb3j0e-wi-core-i3-370m-2-4g >> hz-4gb-320gb-15-5--windows-7-home-premium-64bit-laptop-766T.html >> >> I am not sure what the license is on the wallpaper, or if Sony got >> proper permission, or if anyone even cares (or might even like it), >> but I thought I should bring it to your attention just in case there >> is something that should be done about it. > > Air is LGPLv3 according to its installed metadata. I'll see about forwarding > to the correct list and author. > > Regards, > - Michael Pyne This may not be the fault of sony, it may be the work of the store. There was a VAIO wallpaper on deviantart that was just a VAIO logo slapped on the Air wallpaper, but the account was taken down. I thought that might be the source, but there are other stores that use a green version of Air instead so it may not be. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Thoughts from a former KDE, currently Mozilla developer
On Tue, Dec 7, 2010 at 3:01 PM, Thiago Macieira wrote: > On Tuesday, 7 de December de 2010 20:28:57 Benoit Jacob wrote: >> So do crash reports now automatically land in a database that's easy >> to do queries on? (See the web interface provided by Socorro) >> >> If I want to get a list of all KDE crashes that happened in libGL.so*, >> how do I go about that? >> >> Regarding backtraces, as I said in my next email, it's not realistic >> to expect the user to do anything more than click OK, when an app >> crashed on him. So I think that the -dbg packages rather need to be >> used by the server. > > Server-side debug symbols implies uploading the core file to the server, which > may contain a variety of interesting information like user passwords, credit > card numbers, etc. Imagine if kwalletd crashed even. > > Not to mention that some core files are quite big to upload and store. This may be totally infeasible, but what if you did client-side debugging, but used debugging symbols stored on a server? The debugger would grab the parts of the debugging symbols it needs from the server, do the analysis locally, then submit the results. That way there would be no security risk, but people wouldn't have to keep the debugging symbols installed. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Where to start?
On Sat, Dec 11, 2010 at 11:35 AM, Felix Rohrbach wrote: > Hi, > > first, thanks for your respose! > > Am Freitag, 10. Dezember 2010, 21:00:26 schrieb Aaron J. Seigo: >> On Friday, December 10, 2010, Felix Rohrbach wrote: >> > 1) With which project should I start? >> >> pick something that interests you. there are a lot of kde applications and >> all of them can use more attention and interest. if you pick something >> that interests you (because you use it, or you feel it's something that >> could be made better, or because you find the topic to be >> challenging/interesting) you are more likely, in my experience, to stick >> with it. >> > When I look at the applications I'm interested in they always seem to already > have all the easy-to-implement features I can think of, and all the other > things seem to hard for me as a starting point. But most likely I'm wrong with > that - I just don't have the experience to be able to say which feature is too > hard for me. So it would be really nice if someone could name me one > application (preferably from the section Internet or Multimedia) which has > easy-to-read, not too complicated code and a clear structure and which has > some tasks for a newbie like me. > I know you have junior jobs in your bugzilla, but they seem too little to > really get into a project, at least I would prefer a slightly bigger task. > > Greetings, > Felix Gwenview has several that I know of that shouldn't be too hard. Rekonq is also making a push so it could probably use some help, but I don't know specifically on what. If you are looking for larger jobs, I have some suggestions for amarok, kmix, or dragon player. But these are mostly things I would like to see, so they may be somewhat self-serving. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: UX Developer Sprint Proposal
On Mon, Dec 20, 2010 at 8:55 PM, Celeste Lyn Paul wrote: > Hi Everyone, > > This is information on a UX Developer Sprint proposal in Spring 2011. > Feel free to forward or add whoever you may think would be interested > in this sprint. An organization wiki page is located: > http://community.kde.org/Sprints/UX2011 > > The purpose of this sprint is to provide an opportunity for unbridled > creativity and hacking on new and old KDE user experience (UX) > problems. The goal is to produce 3-4 design specifications and code > prototypes of new interaction and interface concepts that could be > integrated into KDE. This is an opportunity to be part of a innovation > that could lead to the next generation KDE. > > Anyone who is interested should think of at least one idea or concept > they would like to explore during the sprint. The idea can be all but > a twinkle in your eye, or a series of hard requirements. You will be > able to present your idea in a group discussion. We will choose > several topics to explore in more detail, eventually leading to > actionable design specifications and prototype code. > > In many ways, I believe this sprint could fit into Aaron's Elegance > vision from Akademy 2010. Here are two examples of concepts I would > bring as my discussion topics: > > * Integration of webservices in a useful way > We have apps that are desktop portals to data on Facebook and Flickr, > but we don't do anything interesting with it. To remain relevant we > have to use the web, not just interface with it. Why can't we connect > to Facebook as a calendar resource, or add Flickr as a seamless image > location in Digikam and Gwenview? > > * Keeping up with current trends: > We need to consider next-generation toolbars, menus, and windowing. > Browsers have been slowly evolving to optimize toolbars and tabs in > the interface, but other apps remain archaic. Microsoft has worked out > kinks in its "ribbon" toolbar design in the next generation of > productivity apps. We've had very interesting proposals for flexible > UIs and alternative menu designs. Why don't we take a serious look at > proposals like this to see if they are the future? > > My vision for this sprint isn't necessarily to solve existing > problems, but to think forward. KDE 4 is stable. We now have the > freedom to hack and experiment for the future. > > Activities include brainstorming, designing, prototyping, and architecture: > > * Brainstorming: I've provided a sample list of "holes" to fill. What > else could we do? How would we do it? > * Designing: What are possible ways we can provide new ways to > interact with and experience KDE? > * Prototyping: Let's see these ideas in action and code out some of > these problems. What would our ideas look and feel like in KDE? > * Architecture: What new technology needs are there to support our > ideas? Do we need widgets? Libraries? Or just a standardized way of > doing things? > > Sprint deliverables could include: > > * Design mockups exploring new interactions > * Technical specifications for new technology > * Prototype code demonstrating new ideas > > There is no date yet, other than Spring 2011. If you are interested, > please add yourself to the participant list on the wiki page with > possible dates. Also add a topic if you have a particular stone you > would like to crush. If you have any questions about the sprint, or > would like help coming up with a personal topic, feel free to ask. > This is a great opportunity to get a diverse group of problem solvers > together to create something new and shiny. Maybe your idea might even > turn into the next KDE gem :) > > Cheers, > > ~ Celeste If you want some suggestions for topics, I have quite a few, although I am not necessarily sure all are necessarily right for a usability sprint: I wrote a pretty extensive essay on the limitations of input devices with KDE: http://neverendingo.blogspot.com/2010/11/matter-of-control-state-of-input-device.html There are also more clearly usability-related issues with the configuration tools currently available. In my opinion this is the single biggest flaw in all of KDE, but I appear to be in the minority on that. Your idea about integration of web services is good. I suggest looking at this brainstorm idea, which deals with those very issues (this isn't may idea, but I think it is a good one): http://forum.kde.org/brainstorm.php#idea87355 The idea and discussion is about sing kio to allow easy access to web services like web storage, image hosting, and so on. I think it touches on another issue: kio slaves are pretty under-utilized in KDE. They provide a lot of potential for seemlessly integrating services, local and online, into your file browser, but there are few available outside of dedicated network share access. As an example, there are kio slaves for a couple compressed file formats that let you seemlessly browse those folders as though they were files, but the vast majority of comp
Re: UX Developer Sprint Proposal
On Mon, Dec 20, 2010 at 8:55 PM, Celeste Lyn Paul wrote: > Hi Everyone, > > This is information on a UX Developer Sprint proposal in Spring 2011. > Feel free to forward or add whoever you may think would be interested > in this sprint. An organization wiki page is located: > http://community.kde.org/Sprints/UX2011 > > The purpose of this sprint is to provide an opportunity for unbridled > creativity and hacking on new and old KDE user experience (UX) > problems. The goal is to produce 3-4 design specifications and code > prototypes of new interaction and interface concepts that could be > integrated into KDE. This is an opportunity to be part of a innovation > that could lead to the next generation KDE. > > Anyone who is interested should think of at least one idea or concept > they would like to explore during the sprint. The idea can be all but > a twinkle in your eye, or a series of hard requirements. You will be > able to present your idea in a group discussion. We will choose > several topics to explore in more detail, eventually leading to > actionable design specifications and prototype code. > > In many ways, I believe this sprint could fit into Aaron's Elegance > vision from Akademy 2010. Here are two examples of concepts I would > bring as my discussion topics: > > * Integration of webservices in a useful way > We have apps that are desktop portals to data on Facebook and Flickr, > but we don't do anything interesting with it. To remain relevant we > have to use the web, not just interface with it. Why can't we connect > to Facebook as a calendar resource, or add Flickr as a seamless image > location in Digikam and Gwenview? > > * Keeping up with current trends: > We need to consider next-generation toolbars, menus, and windowing. > Browsers have been slowly evolving to optimize toolbars and tabs in > the interface, but other apps remain archaic. Microsoft has worked out > kinks in its "ribbon" toolbar design in the next generation of > productivity apps. We've had very interesting proposals for flexible > UIs and alternative menu designs. Why don't we take a serious look at > proposals like this to see if they are the future? > > My vision for this sprint isn't necessarily to solve existing > problems, but to think forward. KDE 4 is stable. We now have the > freedom to hack and experiment for the future. > > Activities include brainstorming, designing, prototyping, and architecture: > > * Brainstorming: I've provided a sample list of "holes" to fill. What > else could we do? How would we do it? > * Designing: What are possible ways we can provide new ways to > interact with and experience KDE? > * Prototyping: Let's see these ideas in action and code out some of > these problems. What would our ideas look and feel like in KDE? > * Architecture: What new technology needs are there to support our > ideas? Do we need widgets? Libraries? Or just a standardized way of > doing things? > > Sprint deliverables could include: > > * Design mockups exploring new interactions > * Technical specifications for new technology > * Prototype code demonstrating new ideas > > There is no date yet, other than Spring 2011. If you are interested, > please add yourself to the participant list on the wiki page with > possible dates. Also add a topic if you have a particular stone you > would like to crush. If you have any questions about the sprint, or > would like help coming up with a personal topic, feel free to ask. > This is a great opportunity to get a diverse group of problem solvers > together to create something new and shiny. Maybe your idea might even > turn into the next KDE gem :) > > Cheers, > > ~ Celeste Considering the timing, this might also be a good opportunity to get some ideas and discussion about how KDE applications can make use of activities. I think a big goal of KDE SC 4.7+ will be implementing activity support in individual applications, so this would be a good idea to get some discussions going on that. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Moving/Copying Files] Overwriting identical files
On Sun, Oct 3, 2010 at 3:58 AM, todd rme wrote: > On Thu, Sep 30, 2010 at 7:30 AM, Matthias Fuchs wrote: >> Hi, >> >> When moving and copying multiple files it can be quite tedious to make out if >> there are differences for all these files. >> >> >> >> Use Case: >> You copy hundreds of text files, knowing that most are the same, but not all. >> Now you are greated with multiple "Do you want to overwrite XY size Z with XY >> size W" dialogs. >> >> Proposal >> What I propose is to not show this dialogs if both files are identical, in >> the >> case of copying nothing should happen then, while in the case of moving the >> source file should be deleted. >> >> To check if a file is identical this should happen in a two step process: >> 1. Both file sizes equal and smaller a fixed size >> 2. Calculating the checksums for both files, the check for the fixed size >> above avoids long lasting calculations >> >> If 1. turns out to be false a dialog should be shown. >> >> >> This could be either opt-in (via a checkbox) or always on with just an >> information text in the dialog. The hash function should be one that is very >> fast to calculate and if the file system supports and stores checksums for >> files those should be used. >> >> Open Questions + Discussion >> What do you think of this idea, should something like that be implemented? >> Also what do you think of the Nepomuk Ressources associated with the files? >> Imagine both files have a different rating, what should happen then? >> >>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe >>>> << >> > > I posted brainstorm forum idea about this last year: > > http://forum.kde.org/brainstorm.php#idea39563_page1 > > I proposed a three-stage process, similar to yours but with an extra > stage, an optional byte-by-byte check. > > Checksums are fast for small files, but they can take longer on large > files and on older systems. They also, as I understand it, are not > perfect. So I think that a better approach is that, for files under a > certain size, an automatic three-stage approach is used. First the > file size check, then checksum, then byte-by-byte. If all of those > pass, then the file is just deleted. > > For slightly bigger files, where the checksum is fast enough but the > byte-by-byte is not, only the first two stages are used. If they both > pass, the "File Already Exists" dialog box should be changes to tell > the user that the files are "probably" the same, and gives them the > additional option (on top of renaming, overwriting, and skipping) of > doing an "Exact check" (or something along those lines), which then > does the byte-by-byte check. If that passes, then the file is > deleted. > > If the file is really big, then even the checksum is not done > automatically. If the files have the same size, the user is told the > files have the same size, and the user has the additional options of > doing a "Quick check" and "Exact check" (checksum and byte-by-byte, > respectively). If the checksums match, you are back to to the > previous situation where the user is given the option to do the exact > check or do one of the standard actions. If the detailed check > passes, then the file is deleted. > > The issue with the nepomuk data is an issue even without this. When > you are moving files and decide to overwrite conflicting files, even > if they aren't the same. A simple check box for "merge nepomuk data" > or "merge tags" or something like that (if they both have data, of > course) would be very useful independent of this. Sorry for dredging up such an old topic, but I was wondering if this might this make a good GSOC project. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Problematic GHNS implementations
I know this is not the proper place to be discussing bugs, but I am seeing a worrying pattern of problems with GHNS since KDE 4.5. As far as I can tell, there are at least 4 GHNS implementations that are currently broken. The plasmoid GHNS system does not remember the plasmoids you installed after a reboot, so the list of installed widgets always remains empty. Both the plasma theme and window decoration theme do not remember updates, so if you apply an update, close the GHNS dialog, then open it again the updates are still listed. The Dolphin service menu GHNS interface always fails during installation. There maybe other problems as well, but these are the ones I have personally run into. As I said, these problems have been around since at least KDE 4.5, and are still around in KDE 4.6. I am not sure whether there is a single problem that is causing random difficulties in multiple places, or multiple different problems. However, since these bugs are in multiple different places, and the start seems to roughly coincide with the adoption of the new GHNS system, I thought it was at least possible that there is a pattern that isn't apparent looking at the individual issues. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Problematic GHNS implementations
On Mon, Feb 14, 2011 at 7:51 AM, Sebastian Kügler wrote: > On Sunday, February 13, 2011 18:20:10 todd rme wrote: >> I know this is not the proper place to be discussing bugs, but I am >> seeing a worrying pattern of problems with GHNS since KDE 4.5. As far >> as I can tell, there are at least 4 GHNS implementations that are >> currently broken. The plasmoid GHNS system does not remember the >> plasmoids you installed after a reboot, so the list of installed >> widgets always remains empty. Both the plasma theme and window >> decoration theme do not remember updates, so if you apply an update, >> close the GHNS dialog, then open it again the updates are still >> listed. The Dolphin service menu GHNS interface always fails during >> installation. There maybe other problems as well, but these are the >> ones I have personally run into. >> >> As I said, these problems have been around since at least KDE 4.5, and >> are still around in KDE 4.6. I am not sure whether there is a single >> problem that is causing random difficulties in multiple places, or >> multiple different problems. However, since these bugs are in >> multiple different places, and the start seems to roughly coincide >> with the adoption of the new GHNS system, I thought it was at least >> possible that there is a pattern that isn't apparent looking at the >> individual issues. > > Bugnumbers? If these have not been reported, that would be a good first > step... https://bugs.kde.org/show_bug.cgi?id=214054 https://bugs.kde.org/show_bug.cgi?id=234265 https://bugs.kde.org/show_bug.cgi?id=256473 -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Moving/Copying Files] Overwriting identical files
On Thu, Feb 24, 2011 at 6:12 AM, Aston wrote: > What I'd really like to see is for the "Do you want to overwrite" dialogues to > come up before any files are copied, so it scans the directory first for any > directories and files which have the same name, and prompts the user to > confirm > the actions on all of them before copying anything. > > I'm sure we've all walked away from a computer copying a large amount of > files, > only to find out when we come back that it's been waiting for us to respond to > a prompt for the last twenty minutes. They don't always come that early and > close together. > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << > Actually, I suggested this is part of a larger GSOC project to David Faure already. He seemed to like the idea but I haven't gotten confirmation to put it on the wiki. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Moving/Copying Files] Overwriting identical files
On Wed, Feb 23, 2011 at 12:10 PM, Matthias Fuchs wrote: > Am Dienstag 08 Februar 2011, 23:22:49 schrieb todd rme: >> On Sun, Oct 3, 2010 at 3:58 AM, todd rme wrote: >> > On Thu, Sep 30, 2010 at 7:30 AM, Matthias Fuchs wrote: >> >> Hi, >> >> >> >> When moving and copying multiple files it can be quite tedious to make >> >> out if there are differences for all these files. >> >> >> >> >> >> >> >> Use Case: >> >> You copy hundreds of text files, knowing that most are the same, but not >> >> all. Now you are greated with multiple "Do you want to overwrite XY >> >> size Z with XY size W" dialogs. >> >> >> >> Proposal >> >> What I propose is to not show this dialogs if both files are identical, >> >> in the case of copying nothing should happen then, while in the case of >> >> moving the source file should be deleted. >> >> >> >> To check if a file is identical this should happen in a two step >> >> process: 1. Both file sizes equal and smaller a fixed size >> >> 2. Calculating the checksums for both files, the check for the fixed >> >> size above avoids long lasting calculations >> >> >> >> If 1. turns out to be false a dialog should be shown. >> >> >> >> >> >> This could be either opt-in (via a checkbox) or always on with just an >> >> information text in the dialog. The hash function should be one that is >> >> very fast to calculate and if the file system supports and stores >> >> checksums for files those should be used. >> >> >> >> Open Questions + Discussion >> >> What do you think of this idea, should something like that be >> >> implemented? Also what do you think of the Nepomuk Ressources >> >> associated with the files? Imagine both files have a different rating, >> >> what should happen then? >> >> >> >>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to >> >>>> unsubscribe << >> > >> > I posted brainstorm forum idea about this last year: >> > >> > http://forum.kde.org/brainstorm.php#idea39563_page1 >> > >> > I proposed a three-stage process, similar to yours but with an extra >> > stage, an optional byte-by-byte check. >> > >> > Checksums are fast for small files, but they can take longer on large >> > files and on older systems. They also, as I understand it, are not >> > perfect. So I think that a better approach is that, for files under a >> > certain size, an automatic three-stage approach is used. First the >> > file size check, then checksum, then byte-by-byte. If all of those >> > pass, then the file is just deleted. >> > >> > For slightly bigger files, where the checksum is fast enough but the >> > byte-by-byte is not, only the first two stages are used. If they both >> > pass, the "File Already Exists" dialog box should be changes to tell >> > the user that the files are "probably" the same, and gives them the >> > additional option (on top of renaming, overwriting, and skipping) of >> > doing an "Exact check" (or something along those lines), which then >> > does the byte-by-byte check. If that passes, then the file is >> > deleted. >> > >> > If the file is really big, then even the checksum is not done >> > automatically. If the files have the same size, the user is told the >> > files have the same size, and the user has the additional options of >> > doing a "Quick check" and "Exact check" (checksum and byte-by-byte, >> > respectively). If the checksums match, you are back to to the >> > previous situation where the user is given the option to do the exact >> > check or do one of the standard actions. If the detailed check >> > passes, then the file is deleted. >> > >> > The issue with the nepomuk data is an issue even without this. When >> > you are moving files and decide to overwrite conflicting files, even >> > if they aren't the same. A simple check box for "merge nepomuk data" >> > or "merge tags" or something like that (if they both have data, of >> > course) would be very useful independent of this. >> >> Sorry for dredging up such an old topic, but I was wondering if this >> might this make a good GSOC project. >> >> -Todd >> >> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to >> >> unsubscribe << > > I just saw your reply now. > Personally I don't really think that this should be a GSOC since I believe it > would be quite easy to realise. > What about as part of a larger duplicate file-finding tool? There is no good KDE GUI that I am aware of. Someone could make a general duplicate file check library for kdelibs, include this in the file overwrite dialog but also make a GUI to allow scanning directories for duplicate files. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Problematic GHNS implementations
On Mon, Feb 21, 2011 at 5:27 AM, Matthias Fuchs wrote:
> Am Montag 14 Februar 2011, 15:35:31 schrieb todd rme:
>> On Mon, Feb 14, 2011 at 7:51 AM, Sebastian Kügler wrote:
>> > On Sunday, February 13, 2011 18:20:10 todd rme wrote:
>> >> I know this is not the proper place to be discussing bugs, but I am
>> >> seeing a worrying pattern of problems with GHNS since KDE 4.5. As far
>> >> as I can tell, there are at least 4 GHNS implementations that are
>> >> currently broken. The plasmoid GHNS system does not remember the
>> >> plasmoids you installed after a reboot, so the list of installed
>> >> widgets always remains empty. Both the plasma theme and window
>> >> decoration theme do not remember updates, so if you apply an update,
>> >> close the GHNS dialog, then open it again the updates are still
>> >> listed. The Dolphin service menu GHNS interface always fails during
>> >> installation. There maybe other problems as well, but these are the
>> >> ones I have personally run into.
>> >>
>> >> As I said, these problems have been around since at least KDE 4.5, and
>> >> are still around in KDE 4.6. I am not sure whether there is a single
>> >> problem that is causing random difficulties in multiple places, or
>> >> multiple different problems. However, since these bugs are in
>> >> multiple different places, and the start seems to roughly coincide
>> >> with the adoption of the new GHNS system, I thought it was at least
>> >> possible that there is a pattern that isn't apparent looking at the
>> >> individual issues.
>> >
>> > Bugnumbers? If these have not been reported, that would be a good first
>> > step...
>>
>> https://bugs.kde.org/show_bug.cgi?id=214054
>> https://bugs.kde.org/show_bug.cgi?id=234265
>> https://bugs.kde.org/show_bug.cgi?id=256473
>>
>> -Todd
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> unsubscribe <<
>
> I mentioned these problems months ago. The reason for them are not wrong
> implementations in the programs but GHNS itself.
>
> GHNS does not share its cache between instances of GHNS in the same app and
> between apps.
>
> The first issue would have been solved by [1] which I forgot about.
> I tried to discuss the second issue in kde-core-devel [2] but it never really
> took off -- no GHNS developer involvment -- so I forgot about that as well.
>
> Basically all this means that it was impossible for me to add a working auto-
> update mechanism in the comic plasmoid.
>
> The reason for updates being displayed as updateable despite being updated
> already is likely this line [3] which I also reported.
>
> I talked about all these problems but did not get much or any feedback, seems
> familiar to your situation. :D
> So I simply supposed that I am the only one which sees or has that problem and
> moved to something else to work on and forgot about it relatively fast.
>
> If you want you can take what I did work on (1 + 3) and implement it if it
> fixes the problems, as I am not really willing to work on it anymore.
> There are other projects which I find more interesting and where I get more
> feedback and further time is scarce, reading the ml now should have been a
> small break. :D
> Same goes for 2, though my first tries never took off and it was a pita, the
> GHNS code base is imo not really suited for that.
>
>
> [1] http://reviewboard.kde.org/r/5528/
> [2] http://lists.kde.org/?l=kde-core-devel&m=128785351717032&w=2
> [3]
> --- a/knewstuff/knewstuff3/core/installation.cpp
> +++ b/knewstuff/knewstuff3/core/installation.cpp
> @@ -304,7 +304,7 @@ void Installation::install(KNS3::EntryInternal entry,
> const QString& downloadedF
> if (!entry.updateVersion().isEmpty()) {
> entry.setVersion(entry.updateVersion());
> }
> - if (!entry.updateReleaseDate().isValid()) {
> + if (entry.updateReleaseDate().isValid()) {
> entry.setReleaseDate(entry.updateReleaseDate());
> }
> }
>
It seems strange that something as fundamental and pervasive as GHNS
could be this broken without anyone caring about it. Does nobody else
have these problems? Or are, for example, plasma developers not
bothered by the fact that installing plasmoids and updating plasma
themes are both broken? For a technology that KDE pushes so hard to
be broken at a pretty fundamental level seems to be a serious issue.
Unfortunately, looking at the patch it looks like it is beyond my
abilities to work on.
-Todd
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Problematic GHNS implementations
On Thu, Feb 24, 2011 at 4:15 PM, Sebastian Kügler wrote: > On Thursday, February 24, 2011 20:34:22 todd rme wrote: >> Or are, for example, plasma developers not >> bothered by the fact that installing plasmoids and updating plasma >> themes are both broken? > > Can't speak for anybody else, but it's not something I'm testing regularly. > > Yes, I care; no my time is not unlimited, and until that happens, we have to > keep our cool and stay friendly with each other, and not accuse each other of > carelessness. > -- > sebas I am not accusing anyone of carelessness, I am just surprised plasma developers aren't more involved in the discussion. Installing scripted plasmoids and installing themes are two of the most visible parts of plasma, so since those are broken I would have thought plasma developers would be amongst the first to get involved in a discussion about getting them working. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Future of KSysguard - removing remote monitoring
On Tue, Mar 8, 2011 at 9:15 AM, John Tapsell wrote: > Hi all, > > For the past 13 years or so, ksysguard has been in KDE under various > names. Right from the beginning it was designed to monitor remote > systems as well as local ones. > > To monitor remote systems, it can connect to a remote machine via > rsh, ssh, etc, and communicate via a very simple plain text protocol. > > However over the years this design has slowly strangled future > development, and has scared off several contributors. People have a > great idea and want to add it, then as I start to explain how they > need to implement it, their eyes get wider as they start to back away > slowly. > > So unless anyone can talk me out of it now, I am going to remove the > ability to monitor remote hosts entirely, and to use one of the many > excellent cross-platform debugged libraries that already exist to > gather system information. > > John Is there any way to make the monitoring less restrictive without eliminating it entirely? For instance making a new protocol that is able to use information with less restrictions on the data format? -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Wayland screen locking and KDE
There is a discussion going on about how Wayland will be handling screen locking: http://lists.freedesktop.org/archives/wayland-devel/2011-April/000874.html However, from the discussion, I am a little concerned how this would work with, for instance, plasmoids on the screensaver. I don't know the technical details about either Wayland or the plasma screensaver, but just in case there really are such conflicts I thought I should bring it to your attention. It is obviously better to make sure Wayland supports what KDE needs initially rather than trying to get major changes implemented later. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
dbus-python and gnome
I am not sure the best mailing list for this, but it seems of general importance so I am sending it here. A little background: If you use python, you are probably aware that there is currently a big push underway to switch from pythong 2 to python 3. Most major distributions will probably be switching within the next couple of releases. KDE's python bindings and pyqt4 have supported python 3 for a while, I believe. However, a big piece is missing for desktop users: the dbus python bindings currently only support python 2. There was some effort to port to python 3, but it has stalled, as you can see in the following bug report: https://bugs.freedesktop.org/show_bug.cgi?id=26420 The problem is the solution of the dbus-python maintainers. They appear to be coming to the conclusion that they should abandon dbus-python entirely, and switch to the glib python bindings instead. The problem here is that the glib dbus implementation uses GIO. In other words, the recommended dbus python bindings will have a hard dependency on Gnome. Since KDE and Qt use dbus heavily, the KDE and Qt python bindings would also depend on Gnome. Their suggestion for Qt is to make their own independent dbus bindings from scratch. The problem here is that there will no longer be any DE-independent python bindings for dbus, for instance for command-line programs. At least for python, dbus will go from being a desktop-independent solution to one tied to a particular desktop environment. This may not be that big of a deal, but it doesn't seem like a good solution to me. I thought it would be worthwhile bringing this to your attention before any decision is set in stone. It may be too late now to change it, but I suspect that developers would have a better chance of making a change than I would. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KJob: chaining and synchronizing jobs
On Sun, May 1, 2011 at 2:01 PM, Michael Schuerig wrote: > > I have several KJob jobs, some of which may run in parallel, some depend > on the results of one or more others, and all of them are fallible. The > context is Akonadi, but I think my question is generic. > > I want to retrieve items from several Akonadi collections and act on > them. By the nature of the (prefered) interface, the individual steps > executed asynchronously as KJobs. > > The parts are these: > > I launch several retrieval jobs and want to know when all of them have > finished. If one of them fails, all others are killed and failure is > signaled. > > As far as I can tell, there's no pre-build way to group jobs in such a > way as to be notified when all of them have finished. Therefore, > apparently I need to do the synchronization myself, possibly by > connecting to each jobs result signal and keeping track of how many are > still active. > > For chaining jobs, I need to glue them together so that the result of > one is passed as an argument to the next. Of course, if an error occurs, > the chain ought to be broken. > > For all this I can write very specific code -- and do it again the next > time I want to do something similar. I'd rather not do that. Instead, > I'd like to connect independent pieces that are ignorant of each other. > > > It's time for some code. I've given up on the synchronizing and just > tried some painfully non-generic chaining. > > https://github.com/mschuerig/akonadiexport > > I don't like that code at all, but I'm lacking a good idea how to > improve it. > > > Michael This issue looks like it is related, at least superficially, to this GSOC project: http://socghop.appspot.com/gsoc/project/google/gsoc2011/munk/13001 -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Fri, May 13, 2011 at 1:38 PM, Parker Coates wrote: > On Fri, May 13, 2011 at 12:41, Hugo Pereira Da Costa wrote: >> Hello Nikos, >>> I noticed that when running in KDE and using the Oxygen style, the >>> windows of my Qt application can be dragged around with the mouse by >>> clicking on any area in the window, not just the title bar. But it >>> behaves strange in my application: window dragging only works in parts >>> of the window that have nothing in them yet. >>> >> Yes. That's the intended behavior of the feature. >> "Drag window from empty areas". >> >>> Note that dragging in those areas shouldn't be possible to begin with. >> "To begin with", Why so ? This feature was asked by several people, >> already supported in other styles (bespin, qtcurve), accepted inside >> kde, and added to oxygen since kde4.5. Also, it can be disabled in the >> front page of "oxygen-settings". >> >>> So the question is: is there a way I can disable this for specific QWidgets? >>> >>> If you wonder about the details of my situation: I use a QScrollArea to >>> display a QWidget (where I'm drawing stuff using custom painting). When >>> the QWidget is small and doesn't yet fill the entire QScrollArea, the >>> not yet filled areas are "draggable". When the QWidget expands and >>> covers these areas, window dragging stops working. >>> >> Again that's the expected behavior, that users, used to the feature >> above, expect, since the not yet covered part of the scrolled area, is >> considered empty. >> >> You can disable the feature on a per widget basis by catching the >> mouse-press event, and *not* passing them to the parent widget. But I >> would think it is not a good idea, since it would break consistency with >> other apps. Better leave it to the user to decide whether to >> enable/disable the feature, system-wise. > > Hello Hugo, > > Is that the recommended way for widgets to opt-out? KPat has been > receiving a lot of bug reports lately from users who are frustrated > because while trying to play too quickly they miss the card they were > aiming for and start dragging on an empty area, which causes the > window to unmaximise and generally causes confusion. > > In KPat's case, much like Nikos', I'm beginning to think it's > reasonable to disable this feature, because the play area in question > is very different conceptually from traditional widgets. Visually the > "widgety" parts of the window are quite distinct from the "gamey" > parts, so I don't think this would really lead to much confusion. The > high rate of clicking and mouse movements in such areas also makes the > issue much more likely to occur. It isn't just KPat, I went through and checked which games have similar problems and put together a list. You can find the list here: https://bugs.kde.org/show_bug.cgi?id=263898 By my count 26 games suffer from this problem. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Sat, May 14, 2011 at 8:19 AM, Michael Jansen wrote: > That is really great guys. But look at the mail from todd. 26 Games reveice > bugs because of that feature? 26! And you guys still consider this a FEATURE? > > Mike > For most games it isn't a major issue, since you aren't normally dragging. That is why there are so many bugs for kpat but so few (if any) for other games. For most games it is more of a consistency issue rather than something that seriously interferes with usability. I would say the proper solution is not to remove the feature, but to fix the games so their drag behavior is visually consistent. Ideally this would be handled at the library end, using tagaro or something, so the individual game developers don't need to worry about it. I don't know if this is possible, though. I personally find the feature very helpful and use it a lot. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Sun, May 15, 2011 at 12:45 PM, Albert Astals Cid wrote: > A Sunday, May 15, 2011, Nikos Chantziaras va escriure: >> No. That would mean that many applications would not be draggable, >> since their creators never tested, don't know, or don't care about KDE. >> The result: an inconsistent mess. > > You mean like the one we have right now? > > Albert What mess? So far we know of one application that is affected by this in a negative manner, and the developer already plans to fix it. Then we have some minor consistency issues, all from one class of application, that users are unlikely to notice unless they are specifically looking for it (most users aren't going to drag on the game board unless the game specifically calls for dragging). I would hardly call that a "mess". So far, the complaints are mostly hypothetical. But in practice it isn't a major issue. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Sun, May 15, 2011 at 5:22 PM, Michael Jansen wrote: > On Sunday 15 May 2011 14:54:27 todd rme wrote: >> >> What mess? So far we know of one application that is affected by this >> in a negative manner, and the developer already plans to fix it. Then >> we have some minor consistency issues, all from one class of >> application, that users are unlikely to notice unless they are >> specifically looking for it (most users aren't going to drag on the >> game board unless the game specifically calls for dragging). I would >> hardly call that a "mess". >> >> So far, the complaints are mostly hypothetical. But in practice it >> isn't a major issue. > > It is not hypothetical. If it were we wouldn't have that many bug reports. I know there are a lot of bug reports for kpat, but I was not aware of bug reports for other programs. And when I say bug reports, I mean actualy improper behavior, not people who just prefer it the other way. > And > weren't you the one saying there are 26 affected games? Now you say one > application. Why? The list of 26 games includes any game where at least part of the game board or playing field is draggable. In few, if any, of the games besides kpat are users actually likely to drag on the game board. So kpat is the only program I am aware of where there is a serious usability problem. For the rest, it is a minor consistency issue. > And let me add kmail and dolphin. Both have that affect active at some really > surprising points. Care to elaborate? -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Regarding kdelibs/kio
On Sun, Jun 5, 2011 at 9:55 AM, Thiago Macieira wrote: > Em Sunday, 5 de June de 2011, às 13:06:07, tushar mehta escreveu: >> Hi all, >> >> I am currently trying to understand how kde applications uses kio >> for doing file related operations. I am currently working on kget and >> as part of my summer of code project task I need to figure out how >> we can have speed limit on transfer using kio protocols like http/ftp. >> >> Do have we have any sample examples or documentation related >> to KIO? > > I don't think there's any documentation on that. Just read the source code, > starting at KIO::Connection. > > But to simplify what you're looking for: kioslaves use blocking methods. They > read from the network one chunk of data and then they send that chunk of data > to the application (via KIO::Connection). The application also uses > KIO::Connection to read that chunk of data. > > When the ioslave fills up the kernel transfer buffer, KIO::Connection will > block, waiting for the application to read from the same buffer. > > In order to implement a rate control in the ioslave, you simply need to > implement a rate control in the application. After the stabilisation phase, > the ioslave will download at the same rate that the application reads from the > slave. Might it be better to put it in KIO::Connection so it can be used more generally? For instance KNewStuff often exceeds the server thresholds, locking out the user for a while. Bandwidth limits could avoid this. It could also be useful if exposed to konqueror or rekonq plugins. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Regarding kdelibs/kio
On Sun, Jun 5, 2011 at 11:04 AM, tushar mehta wrote: > > Question: > Do we have any control on how much data kioslaves will read from network > and put into kernel buffer? > and if application is taking out the data from kernel buffer at some rate > then > it will be specific to that application and other applications which are > using same > type of slaves will not have the speed control on the data which they are > dealing with. > Can we do something so that KIO it self will fill the kernel buffer at some > configurable rate? I'm not sure I would want one application being able to tell all the other applications what they are and are not allowed to do with their own data. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Regarding kdelibs/kio
On Sun, Jun 5, 2011 at 11:17 AM, tushar mehta wrote: > On Sun, Jun 5, 2011 at 2:38 PM, todd rme wrote: >> >> On Sun, Jun 5, 2011 at 11:04 AM, tushar mehta wrote: >> > >> > Question: >> > Do we have any control on how much data kioslaves will read from network >> > and put into kernel buffer? >> > and if application is taking out the data from kernel buffer at some >> > rate >> > then >> > it will be specific to that application and other applications which are >> > using same >> > type of slaves will not have the speed control on the data which they >> > are >> > dealing with. >> > Can we do something so that KIO it self will fill the kernel buffer at >> > some >> > configurable rate? >> >> I'm not sure I would want one application being able to tell all the >> other applications what they are and are not allowed to do with their >> own data. >> >> -Todd > > but if we are making some changes in KIO then those applications which > are using the KIO will get affected. right? > so say if KIO is transferring data at some particular rate then all the > applications > which are using that KIO, will follow the rate. No, it would be made on a per-connection basis, not a per kio-slave basis. So each time an application tries to transfer a file it can optionally set a bandwidth limit for that one transfer. This would have no affect on any other transfers, and this would be a strictly opt-in feature (applications that don't set a transfer limit would not have a transfer limit). The problem with this approach, I just realized, is that it may make it impossible to change the transfer rate during a transfer. So say you want to set a limit for all transfers using kget. If you add a new transfer you would not able to reduce the rate of the other transfers to maintain the same overall rate because the rate was set when the transfer started. Maybe there might be some way to dynamically set the rate, but I am not sure what it would be. Are you in touch with the guy from this project? : http://www.google-melange.com/gsoc/project/google/gsoc2011/munk/13001 He is working on a more general overhaul of the internals of the KIO file transfer system. This may include better per-application and per-kio slave handling of multiple transfers. It would probably be good to stay in touch with him so you can look for any areas of overlap between your projects and coordinate them (or at the very least avoid conflicts). -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Regarding kdelibs/kio
On Sun, Jun 5, 2011 at 11:45 AM, Thiago Macieira wrote: > Em Sunday, 5 de June de 2011, às 14:38:07, tushar mehta escreveu: >> But the problem is that even if KIO is filling up the kernel buffer at some >> rate >> but the application is not reading that data at same rate. Then situation >> will remain same. >> >> Just a thought, it can be wrong also. > > It is wrong. > > The chain is as fast as the slowest link. So if the ioslave is reading at 60 > kB/s from the network and writing that much into the kernel buffer, but the > application is only reading at 4 kB/s, the kernel buffer will grow in size. It > will grow until that buffer reaches its limit, at which point the ioslave will > no longer be able to write. It will block until the application reads a chunk > of data. > > After that point in time, the ioslave's rate will be limited by the > application's read rate. How big is the kernel buffer, on average? Is the connection done on a per-file or per-transfer basis? (i.e. if you copy and paste 20 files in dolphin, is that one connection or 20?) If this is a per-file thing, and it is in the hundreds of kilobytes to a few megabytes, the buffer may never fill. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: The Future of our Frameworks
On Mon, Jun 6, 2011 at 7:26 PM, Sebastian Kügler wrote: > Hi all, > > You've probably been aware that a rather sizable group of KDE developers and > stakeholders in our development platform is meeting in Randa, Switzerland to > discuss the future of our development frameworks, with the big topic being > "modularization of kdelibs". We've had a number of great discussions here > about various technical and process-related topics. We are still in the > process of making the results digestable, transforming our notes into > something that is understandable for those that haven't been able to > participate in these -- very productive -- sessions in person. > > Let me already give you some information on the bigger picture we came up with > here, as you are all probably very curious about that. The overall theme was > the modularization of kdelibs, kde-runtime, kdepimlibs, kdepim-runtine and > kdesupport. With Qt5 -- a change in binary interface -- having been announced, > it is a good point in time to introduce some changes to our frameworks that > are only possible if we change the ABI -- which Qt5 will do for us anyway. > > > What is the scope? > > Instead of Platform, we want to consistently use the term "Frameworks", this > includes what we currently refer to as kdelibs, kdepimlibs, kde-runtime, > kdepim-runtime and kdesupport. We explicitely are not talking about our apps > and workspaces, but read on. > > > What do we want to achieve, and why? > > We want to make it possible to use our frameworks in Qt projects without > significant additional dependencies. This means: > > * We reach out to the Qt development community in a more focused way > * We make it easier to use our frameworks > * We lower the barrier for contributions > * We make our frameworks more suitable for mobile and device-spectrum use > cases > * We make it possible to select a specific set of features developers would > like to use > * We improve our QA processes, leading to better quality apps and frameworks > > We want this to happen with ... > * ... no disruption for our users > * ... little to no source incompatibilities > * ... most apps not needing any significant changes > * ... changes, if at all necessary being kept to a minimum > > > What does it mean for users? > > * No disruption > * Most probably invisible > * Short term: Iit becomes easier to run kDE apps outside of the Plasma > workspaces, including other operating systems > * Longer term: We will probably see more apps using KDE technology > > > What does it mean for developers? > > * We will maintain source compabitility as much as possible > * The impact for existing apps will be minimal > * We will provide a compabitility library as additional measure to reduce the > impact of these changes > > > What does it mean for packagers? > > * We make it possible to ship our frameworks in a more modular way > * We also plan to provide "monolithic tarballs" much as we do now, depending > on the needs and preferences of downstreams > > > Please note that this is *not* KDE5, as it doesn't refer to our community, but > about our development frameworks. At this point there is also no benefit in > talking about KDE 5, since that just opens the door to misinformation. This is > also clearly not about our workspaces, or applications. (See > http://vizzzion.org/blog/2011/06/there-is-no-kde5/ for a quick explanation.) > > In order to prevent this thread from growing into an unmanageable load of > hundreds of emails, please post specific questions as separate threads. (You > can of course reply with praise to this, but anything that is likely to spark > a more detailed discussion is probably better off in a separate thread.) > > Thanks for your attention, and cheers from a wonderful Switzerland, It is great to hear that you are thinking about this, and I am looking forward to seeing more details in the future. As for new threads, are you looking for suggestions and ideas or only questions at this point? -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Qt-only Oxygen style
On Fri, Jun 24, 2011 at 9:02 PM, Luis Gustavo Spern Barreto wrote: > Sorry for everything. I just want to say I'm just here to discuss > issues related to KDE development and my question was simple and > straightforward. I just wanted to get answer to my question. Was there something insufficient regarding Hugo's response? On Thu, Jun 23, 2011 at 9:36 AM, Hugo Pereira Da Costa wrote: > Not on the short term at least. Oxygen uses (and benefits from) part of > the utilities of kdelibs, for > - configuration handling (kconfig) > - color handling (kcolorutils, kcolorscheme) > > Getting rid of these dependencies would mean duplicating this -otherwise > perfectly working- code (either directly or stripped-down), which is not > desirable. However, since kdelibs is going through some modularization > effort right now, I'll try to jump in and make sure these two guys end > up in lightweight independent libraries that oxygen could build against > without additional dependencies, apart from Qt. > > Hugo >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: why are bugs ignored over months?
On Wed, Sep 21, 2011 at 2:10 PM, Reindl Harald wrote: >> Getting nasty and impatient helps nobody, is not constructive, is not >> polite, doesn't teach anyone a lesson or makes anyone eager to please you. >> It's counter-productive. > > i agree - but what should you do as user if a bug hits you multiple each hour > since half a year and their is not other feedback as "me too"? Do what everyone else does and go through the proper channels. Everyone has their own pet bugs, but you don't see many emails on the mailing lists like this. Why do you think that is? -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: why are bugs ignored over months?
On Wed, Sep 21, 2011 at 2:18 PM, Reindl Harald wrote: > > > Am 21.09.2011 14:14, schrieb todd rme: >> On Wed, Sep 21, 2011 at 2:10 PM, Reindl Harald >> wrote: >>> i agree - but what should you do as user if a bug hits you multiple each >>> hour >>> since half a year and their is not other feedback as "me too"? >> >> Do what everyone else does and go through the proper channels. > > what are the "proper channels"? > i thought bugtracker is The bugtrack is, this mailing list is not. >> Everyone has their own pet bugs, but you don't see many emails on the >> mailing lists like this. Why do you think that is? > > i can not say much about this because i subscribed to the devel-list > today only because bugzilla does not interest upstream and update to > 4.7.1 today with no chance made me tired I've had bugs in the bug tracker a lot longer than that, yet you don't see me, or practically anyone else, spamming mailing lists demanding that someone fix our problem. If we did, the mailing list would be so swamped with such emails it would be impossible to use it for anything productive. We use bugs.kde.org and not the mailing lists for these sorts of discussions for a reason. You are being very inconsiderate to the large number of other people who also have bugs they want to be fixed but are trying to do the right thing by not swamping the mailing lists with these sorts of demands. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Fri, Sep 30, 2011 at 11:56 AM, Sven Burmeister wrote: > Am Donnerstag, 29. September 2011, 13:25:49 schrieb Sebastian Kügler: >> > It's frustrating for users submitting bug reports when an easily >> > reproducible bug sits in the queue, without even a comment, for six >> >> > months. For the record, I'm referring to this bug report here: >> This posting of bugreports to mailinglists is often seen as unnecessary, and >> unfair since you're bringing attention to your pet bugs, which >> disadvantages others' pet bugs. Please don't do it, your bug likely ends up >> lower on developers' priority lists, and it sometimes causes bad blood (as >> can be seen in recent history). > > Ok, so if a user reports a bug and gets no answer for weeks, what should he > do? Keep posting to the bug every few weeks, blog about it, private email to > the dev, ask on IRC (which would not be much different than a mailinglist), > post to the forums? If that makes no sense to start not caring about the bug. > Not a good choice, is it? I don't think any of those are good options, since all of them have the same result: spamming developers with huge amounts of useless information. This would only make it far more difficult to manage bug reports. Just being patient seems like the only solution that could work in practice on a large scale. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Fri, Sep 30, 2011 at 5:33 PM, Rui Maciel wrote: > On 09/30/2011 01:29 PM, todd rme wrote: >> >> I don't think any of those are good options, since all of them have >> the same result: spamming developers with huge amounts of useless >> information. This would only make it far more difficult to manage bug >> reports. Just being patient seems like the only solution that could >> work in practice on a large scale. > > Inquiring about the state of a piece of work which a person is responsible > for is not "huge amounts of useless information". If some of these bugs are > patiently left unaddressed then we end up where we are right now: with bugs > left open for years, with the whole bug report process being left broken and > with users wasting their time filing bug reports which will never be > addressed. How is this a better way of handling things? If they don't have time to respond to all the bug reports, what makes you think they would have time to respond to just as many, if not more, emails? You would only be increasing the amount of stuff they need to read, further decreasing the amount of time they have to respond to bugs, not to mention fix them. In the end you would end up with the same situation: tons of emails left unanswered. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Sat, Oct 1, 2011 at 10:52 PM, Rui Maciel wrote: > On 09/30/2011 07:17 PM, todd rme wrote: >> >> If they don't have time to respond to all the bug reports, what makes >> you think they would have time to respond to just as many, if not >> more, emails? You would only be increasing the amount of stuff they >> need to read, further decreasing the amount of time they have to >> respond to bugs, not to mention fix them. In the end you would end up >> with the same situation: tons of emails left unanswered. > > The main problem is not how many messages, either those sent to this mailing > list or to the bug tracker, are left unanswered; it's how much time is > being wasted on a futile task. This problem is being incorrectly depicted > as one which only affects developers but in reality it affects every person > involved, including users. That's right. The more things they have to read, the less time they have to develop. Sending what amounts to duplicate bug reports is not going to help that, it is going to make it worse. Further, it would require even more time on the part of users as well, sending a ton of emails that would not and could not help the situation. So from a user perspective this approach also makes things worse. > You claimed that developers waste time browsing some messages. Yet, it > should also be noted that filing bug reports, particularly when providing > every piece of information which may be of any interest, does demand quite a > bit of time and energy from the users. In fact, a bug report which is left > untouched by any developer ends up being a complete waste of time for the > user who submitted it, while not affecting any developer in the process. If > you hold this in consideration while you browse through KDE's bug tracker > you will get an idea of how much time the current bug tracking policy is > forcing users to waste. This, as this thread demonstrates, is a > considerable source of frustration. So, if there is really an intention to > cut on how much time is being wasted with the current process then why not > start where it really is being entirely wasted? I am not sure I understand your proposal. My point is that sending emails can only make the situation worse. It will require more time on the part of both users and developers while not addressing the underlying problem: not enough eyes and not enough time. And you don't need to lecture me on frustration with the bug reporting process. I currently have 38 unconfirmed (including 1 major data loss bug) and 17 new bugs. That only includes bugs I reported myself (not ones I have but that there was already a bug for) and it does not include wishlist items. That is exactly why I am against anything that will make it less likely that my bugs will be solved, which is exactly what sending bugs to the mailing list does. The only thing that will improve the situation is having people help in the triage process. I don't do that full-time, but I certainly do point out when bugs are duplicates or already fixed when I see them. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Sun, Oct 2, 2011 at 1:08 PM, Kevin Krammer wrote: > On Saturday, 2011-10-01, Joshua Blocher wrote: >> I think we are acting like it all has to be done manually which is >> simply not true. Why are we tackling bug triage as something that only >> a human can do? > > Because it potentially requires interpretation of natural language text, > understanding of relations between concepts and ideally the ability to combine > those to reproduce the problem. Maybe at the very least it could be used to find likely duplicate backtraces. Currently drkonqi asks that you submit a new bug report if you aren't certain that your backtrace is identical to an existing one (which most users would not be able to do). If it could compare backtraces and identify likely matches hopefully this could cut down a lot on the number of duplicate crash reports. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [KDE Usability] tasks for Google Code-in
On Sat, Oct 15, 2011 at 3:19 PM, Lydia Pintscher wrote: > Heya folks :) > > Google Code-in > (http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/about) > has been announced again for this year. Org applications will start on > Monday and we'll try to get in again given last year's success. The > kids were wonderful. > Google changed the rules a bit this time. If we're accepted we need to > add a large number of tasks at the beginning and can only add a second > round in the middle of the program again. This means we need to start > thinking of good tasks for the kids now. All this small stuff you wish > you had time for - make it a task. If you're unsure if it's suitable > find me in #kde-soc and I'll help you. Tasks can come from the > following areas: > * Code: Tasks related to writing or refactoring code > * Documentation: Tasks related to creating/editing documents > * Outreach: Tasks related to community management and outreach/marketing > * Quality Assurance: Tasks related to testing and ensuring code is of > high quality > * Research: Tasks related to studying a problem and recommending solutions > * Training: Tasks related to helping others learn more > * Translation: Tasks related to localization > * User Interface: Tasks related to user experience research or user > interface design and interaction > > Please think of tasks. I'll go around with a wiki page or similar > later to collect them. Some ideas (they may or may not be appropriate for this): 1. Rewrite individual or small numbers of plasma widgets in QML 2. Write comprehensive unit tests for a particular module 3. Make sure a particular module conforms to its coding style 4. I noticed openSUSE is working on something called openQA for automated testing of software. It might be worth seeing if that could be useful 5. Some sort of easy-to-use tracking and display of page hits and/or search terms for userbase so we know what people are trying to find out or learn 6. Integrate the amarok feedback system into one or more other applications 7. Improve detection and handling of duplicates in Dr. Konqi, such as detecting duplicate backtraces 8. Some sort of fuzzy duplicate search, ideally with some sort of learning algorithm, in bugs.kde.org (or bugzilla in general) that can rank reports in terms of how likely they are to be duplicates to help triagers focus their searches. Bug reports could also be run through this before submission to help users find out if their bugs are duplicates. This could be too difficult for such a project, though. 9. Something in bugs.kde.org to let users report a bug as likely fixed or a likely duplicate. These sorts of reports should probably be prioritized over normal comments since they can help reduce the overall noise in bugs.kde.org, so having a dedicated way to do that would be helpful. Maybe a general way for users to report bugs that should probably be closed but that they do have permission to close themselves. Once again this might be better done in upstream bugzilla. 10. Scientific and technical QML components like plots, axes, meters, dials, LEDs, thermometers, etc. Each person would either do one such component or a small number of them. The goal would be to reproduce the stuff offered by the QWT project in QML. 11. Remove all Qt3support or KDE3support instances from one application or part of one application (depending on the size of the application and number of such instances) 12. Integrate a simple, low-bitrate screencast tool into both KDE and userbase so it is easy to make and upload visual walkthroughs of various tasks. It should ideally be dedicated to this tasks, with annotations and automatically pausing after each stage so the user can do it themselves. 13. Make an interactive problem solver for Userbase that directs people to particular articles based on their responses to a series of questions. 14. Integrate userbase with the existing KDE help system. This would probably involve two projects, one to have userbase search in the help system (but would just show links that open the page in a web browser), and a second to display userbase web pages directly in the help browser. 15. Fix the search in KDE help. Maybe use strigi to index the help and man files. A second project could be something in nepomuk to automatically cross-reference help pages based on the mention of specific applications or tasks in other help pages. 16. Packagekit help integration, to automatically try to download documentation for an application when the documentation cannot be found on the system. This is already available for debuginfo and codec packages so there is a basis someone could use to get this started. 17. Improvements in how .xsession-errors is handled by KDE. Currently applications often dump a large amount of informationt there even when debug data is turned off in kdebugdialog.. 18. Automatically enable and disable debug files. Currently you need to
Re:
On Sun, Nov 13, 2011 at 5:36 AM, Pedro . wrote: > Hi, > I have build and installed kde-baseapps from git master and i got trully > disapointed with dolphin. > Now dolphin when selecting Folders in the left panel appears an empty panel, > the compact vew mode isnt anymore in the i dont have anymore in the icons > toolbar, and whenusing the Detailed Icon View seams to be with a slow > files/folders movement and appearance, and theres no option available so > that the user can avoid this kind of slow movements. > Why is dolphin taking this path? > Due to this i needed to do a checkout to the > SHA 37247c00868a1ee2a84bf7b463cc92b16579f813, thats the SHA previous to the > commit with subject "Merged very early alpha-version of Dolphin 2.0" where > was comitted the start of this development path. > My 2 cents, > Silouck Dolphin 2 is a rewrite of the underlying icon view code in order to drastrically improve performance and fix a number of visual bugs and limitations. However, this means rewriting a lot of code, so it will take time for all the features to be re-implemented. All the old features will be back, they just aren't yet. This is the problem with using the unstable version of KDE, you get unstable and unfinished code. It should be finished by the 4.8 release last I heard, but untill it is finished it will lack some features. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Dolphin in a bad path
On Sun, Nov 13, 2011 at 5:37 AM, Pedro . wrote: > Hi, > I have build and installed kde-baseapps from git master and i got trully > disapointed with dolphin. > Now dolphin when selecting Folders in the left panel appears an empty panel, > the compact vew mode isnt anymore in the i dont have anymore in the icons > toolbar, and whenusing the Detailed Icon View seams to be with a slow > files/folders movement and appearance, and theres no option available so > that the user can avoid this kind of slow movements. > Why is dolphin taking this path? > Due to this i needed to do a checkout to the SHA > 37247c00868a1ee2a84bf7b463cc92b16579f813, thats the SHA previous to the > commit with subject "Merged very early alpha-version of Dolphin 2.0" where > was comitted the start of this development path. > My 2 cents, > Silouck Dolphin 2 is a rewrite of the underlying icon view code in order to drastrically improve performance and fix a number of visual bugs and limitations. However, this means rewriting a lot of code, so it will take time for all the features to be re-implemented. All the old features will be back, they just aren't yet. This is the problem with using the unstable version of KDE, you get unstable and unfinished code. It should be finished by the 4.8 release last I heard, but untill it is finished it will lack some features. edit: sorry for the double-post, I saw the no-subject version of this email before this one. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: SIP client
On Mon, Dec 12, 2011 at 1:19 AM, Anton Cherkasov wrote: > Hi all! > > There really is no normal SIP client for KDE4? > Kcall and KPhone is completely unusable, and Twinkle is based on Qt 3. > Do we have any project for that? I think telepathy will or already does support this. it is intended as a generic cross-desktop chat and VOIP interface, with both KDE and GNOME GUIs for it on one end and plugins that provide connections to various chat and VOIP services on the other end. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Qt migration efforts
On Mon, Dec 12, 2011 at 8:24 AM, Gravis wrote: > there are a lot of basic and advanced things in Qt that KDE isnt using > but using their own implementation or variant. this may be an issue of > code being merged into Qt and the KDE code not being deprecated but i > can't say for certain. > > -Gravis Just because there are libraries in KDE and Qt with similar names does not mean the two libraries provide the same features or same capabilities. In a lot of those cases, maybe all of them, it is more a case of the Qt version not having features that the KDE applications need. With Qt5 and open governance it is possible to merge those features into Qt, and that is one of the primarily goals for frameworks. However, this often cannot be done without breaking backwards compatibility with both KDE and Qt, so it is not something done lightly. You can't just outright replace the Qt version with the KDE version, since that would break things for other Qt users (the KDE and Qt versions can have wildly different APIs), and it may lose features or performance benefits the Qt version has that the KDE version does not. Or the KDE version may not be optimal either, so it is better to plan ahead and make something better than both. Whatever the case, it is not as simple to just switch to the Qt versions of libraries as you make it out to be. There are different KDE and Qt versions of libraries precisely because the KDE and Qt versions are not equivalent. If they were, the KDE versions would be marked as deprecated. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KIO-MTP development
On Fri, Jan 13, 2012 at 3:52 PM, Philipp Schmidt wrote: > Hi all, > > > > this week I started developing a KIO-Slave for MTP since I now have a Galaxy > Nexus and like accessing it via Dolphin and not having to use mtpfs. You can > find it on github: > > > > https://github.com/hefeweiz3n/kio-mtp > > > > So far it can do very little (Basically listing devices, storages and files > works, if the right kio-instance gets the cache), but I am working on that. > > > > Since concurrent access to the devices using libmtp is buggy at best I would > like to introduce a persistent cache that gets updated when changing > operations occur or devices get plugged in/removed. Is there any preferred > way in KDE to do that, or an infrastructure already in place? > > > > Also, if you have any other ideas or things to say (for example regarding > the coding style), please do ;). My long term goal is to get this integrated > into KDELibs, together with a Solid-Component that detects MTP-Devices and > shows them in Dolphin etc. Help is also appreciated :). > > > > Regards > > Philipp Schmidt You might also want to forward this to the dolphin and amarok mailing lists, since they may want to be able to use this kio slave for their own mtp access. Having a single mtp access tool would probably be nice. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KIO-MTP development
On Sat, Jan 14, 2012 at 10:09 AM, Bart Cerneels wrote: > On Fri, Jan 13, 2012 at 15:52, Philipp Schmidt wrote: >> Hi all, >> >> >> >> this week I started developing a KIO-Slave for MTP since I now have a Galaxy >> Nexus and like accessing it via Dolphin and not having to use mtpfs. You can >> find it on github: >> >> >> >> https://github.com/hefeweiz3n/kio-mtp >> >> >> >> So far it can do very little (Basically listing devices, storages and files >> works, if the right kio-instance gets the cache), but I am working on that. >> >> >> >> Since concurrent access to the devices using libmtp is buggy at best I would >> like to introduce a persistent cache that gets updated when changing >> operations occur or devices get plugged in/removed. Is there any preferred >> way in KDE to do that, or an infrastructure already in place? >> >> >> >> Also, if you have any other ideas or things to say (for example regarding >> the coding style), please do ;). My long term goal is to get this integrated >> into KDELibs, together with a Solid-Component that detects MTP-Devices and >> shows them in Dolphin etc. Help is also appreciated :). >> >> >> >> Regards >> >> Philipp Schmidt > > If your intention is to enable MTP solely in Amarok I recommend not > making it a KIO slave but rather (re-)implementing the MTP plugin > directly using libmtp. We've done a KIO slave with specialized > functions to work in Amarok for upnp media-server. Coordinating the > release in kdebase with amarok was problematic with the result that > the feature is still not working for some users with older version of > KDE or slightly different setups. And for achieving good MTP > functionality in Amarok going the route of the KIO slave is > objectively over-engineered, with issues like caching to enable > concurrent access as a result. > > I would estimate that a new MTP plugin directly in Amarok would take < > 10% of the time and effort of a KIO slave being used in Amarok. So > please consider what your defined goal is. We've recently > re-implemented the USB Mass Storage and iPod plugins in amarok in > about 5 days work for each. > > Bart The issue is that MTP is now the primary way to move files onto and off of android devices starting with android 4.0, and on some phones (such as the Galaxy Nexus) it is the only way. That is why having first-class MTP access built directly into the file manager would be a huge benefit for KDE. This would also be the case with iPhones, which normally use iTunes to move files, but that would probably take someone with an iPhone who wants to implement it. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Access indexing
On Sat, Feb 18, 2012 at 3:51 PM, Kevin Krammer wrote: > On Thursday, 2012-02-16, Stephan Menzel wrote: >> No, this wouldn't cut it. There's several reasons: >> >> 1) >> Maybe I described confusingly. I want it to search for arbitrary >> filenames (not just applications) and similar expressions _fast_. >> Instantaneously, as the apple thing does. There must be indexing for >> this. Also, besides filenames it shall display search results in meta >> information as well. > > I think what Todd was trying to convey is that there is a KRunner plugin that > does provide matches for the user input by querying Nepomuk and thus the > indexing data gathered through Strigi. > > Your initial posting sounded like a permanent input field (i.e. not a popup > like KRunner) and only displaying matches from the Nepomuk plugin (i.e. not > interleaving those with matches from other plugins). There is already a krunner plugin that provides a permanent input field on the desktop or a panel. However, it is not available from standard KDE packages, it is only on kde-look.org (although some distros do offer packages for it). It may be possible to get such a widget included in plasma-addons. There may be ways within krunner to limit individual krunner interfaces to one runner, or to setup the initial configuration that way. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: GSoC idea: improving scanning and OCR in KDE (skanlite/kooka)
2012/3/6 José Manuel Santamaría Lema : > Hi, > > I'm considering to apply to GSoC this year, and if I do, I would like to > improve the status of scanning and optical character recognition in KDE; being > more specific: > > > What I want to achieve > > > A few years ago I had to study electronics stuff at my university following > class notes only available in paper. I was annoyed because I couldn't use > ctrl+F with a paper, so I investigated a bit about OCR stuff and I found the > open djvu file format[1]. > > So I tried to produce a djvu document with KDE and my free operating system; > it was (very difficult|impossible); if recall correctly I did something like > this: I tried to figure out a workflow scanning a couple of pages as 2 jpeg > files, then I tried to join them in a djvu multipage document using shell > commands, and suceeded. However I couldn't find out how to do the OCR part, > iirc I tried a couple of free ocr programs (I didn't tried ocropus; I don't > remember if either that program didn't exist at that moment or I just didn't > know about it) but their output was just the text without the coordinates > where the texts are located, which would be needed to produce a proper text > layer in the djvu document. > > So I gave up and rebooted on Windows and I used a propietary software to > produce the document; it worked quite well, I just fed the papers in my > scanning device and produced a multipage document; when done I just clicked a > menu item labelled as something "process the document using OCR" and that's > it. I don't remember very well the name of the software I used, but I'd swear > it was "Document Express"[2]. > The result was excellent, and you can download the produced document here: > http://alioth.debian.org/~santa-guest/gsoc2012/apuntes_te.djvu > As you can see, the size of the document is reasonable (only 2.4M) and you can > do ctrlf+F "zener" and read stuff about zener diodes. > > So... to sum up: it was/is easier to produce good djvu documents with > propietary software. I want a KDE'ish program to replace the expensive > "Document Express". > > > Some technical details > > > Currently we have a couple of KDE programs to scan documents: skanlite and > kooka. skanlite is quite simple (doesn't do OCR stuff), uses the modern > liksane > library, it's in extragear and works fine. kooka provided more functionality > in > the KDE 3 old days than skanlite today (seems it was able to do some basic OCR > stuff), uses its obsolete libkscan library, it's in playground and I don't > know > if it works or not because I don't have an scanning device right now, but at > least it builds properly. > > So... looks like the tasks to do to achive my goal would be: > 1. If needed, extend libksane functionality in order to make it a good > replacement for the old libkscan. > 2. Port kooka to the modern libksane. > 3. Add ocropus support to kooka (I heard with ocropus you can get the > coordinates of the texts, but I don't know for sure yet) > 4. Code something in kooka to produce djvu documents. > > > [1]http://en.wikipedia.org/wiki/DjVu > [2]https://www.caminova.net/en/shop/item.aspx?itemid=3 > > I sent this suggestion to the kde-hardware mailing list, but it seems relevant here: Scanner kio slave. An easy scanner interface using file managers (like the current CD ripper kio slave). There would be a folder for each scanner. When the folder is opened it will pull in a preview from that scanner. There would then be folders for supported resolutions, with individual files for common paper sizes, the whole scanner area, auto-detected pictures (i.e. if you can multiple pictures at the same time) and, if available, text files for OCR. Dragging one of these to the filesystem will trigger a full scan with those settings. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: GSoC idea: improving scanning and OCR in KDE (skanlite/kooka)
On Tue, Mar 6, 2012 at 8:03 PM, Klaas Freitag wrote: > On 06.03.2012 18:02, todd rme wrote: >> >> 2012/3/6 José Manuel Santamaría Lema: >> >> Scanner kio slave. An easy scanner interface using file managers >> (like the current CD ripper kio slave). There would be a folder for >> each scanner. When the folder is opened it will pull in a preview >> from that scanner. There would then be folders for supported >> resolutions, with individual files for common paper sizes, the whole >> scanner area, auto-detected pictures (i.e. if you can multiple >> pictures at the same time) and, if available, text files for OCR. >> Dragging one of these to the filesystem will trigger a full scan with >> those settings. > > Thats a nice thought from a technical POV but imo thats not what a user > wants. > Think of typical usecases: > > - I want to scan a pile of photos me and my blue Opel Kadett in 1986. > For that, the scan app should detect the borders, maybe deskew and turn a > bit and save automatically. The kio slave would detect the photos and list them, with previews, as individual image files (one file for each photo). You could then just drag the mage files to where you want to save them. > - I want to scan a letter or newspaper snippet and ocr it. There would be text files of various formats (without previews, of course) listed in the kio slave. You would just grab the text file of the format you want, drag and drop it where you want to save it (or open it in a program), and the image will be scanned, OCRed, and then saved in the chosen format (or opened in the chosen program). > - I want to do a photocopy - that could be a nice plasma app imo, just a > typical copy machine button to press, maybe a switch between color and > grayscale. The app would scan and print automatically. There could probably be a right-click menu item to print the selected file. Actually, being able to print any file in dolphin or konqueror from right-click would be nice, but probably outside the scope of this. > - I want to scan a bunch of form documents and know where a barcode is > located on them, which should be read automatically. Barcode searches seem to be a fairly niche thing for scanned documents, so that might be better as a standalone program that acts on image files of any sort (I think barcode detection would be more useful in a webcam app, actually). If you reall want it the kio slave could have a text file containing all barcode numbers. QR codes (square barcodes) are a different story, and I think would be great in the kio slave. The kio slave could detect the QR code, figure out what content it displays, then display a file for that content. For instance a QR code for a URL would show up in the KIO slave as an HTML file that when clicked would open the URL in the default browser. A QR code for an address or coordinates could have a file that would show it in marble. Contacts or emails could also be displayed as corresponding files as well. > These kind of things. Not sure if a kio is cool for any of these. > > Klaas A gui able to do all the things you listed would necessarily be extremely complicated and likely difficult to use, unless most of the tasks were automated push-button affairs. In the latter case, there is little advantage over a kio slave. I would think that a kio slave would be more natural, since users would not need to know terminology or the menu structure. For instance, you could offer an OCR button, but what about people who don't know what OCR stands for (my parents, for example)? On the other hand, with a kio slave, the person is looking to get text, the want a text file, so it should be pretty obvious that is what they want. Similarly, with scanning multiple photos at the same time, in a stand-alone program the user would need to know where to go to get that. On the other hand, in a kio slave they will see files with previews for their individual photos, so it should be clear that is what they are looking for. Note that the kio slave doesn't preclude a more advanced interface, they could both be GUIs for a shared set of underlying libraries. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: GSoC idea: improving scanning and OCR in KDE (skanlite/kooka)
On Wed, Mar 7, 2012 at 10:46 AM, Andreas Pakulat wrote: > On 07.03.12 10:23:32, todd rme wrote: >> On Tue, Mar 6, 2012 at 8:03 PM, Klaas Freitag wrote: >> > On 06.03.2012 18:02, todd rme wrote: > [...] >> > These kind of things. Not sure if a kio is cool for any of these. >> >> A gui able to do all the things you listed would necessarily be >> extremely complicated and likely difficult to use, unless most of the >> tasks were automated push-button affairs. In the latter case, there >> is little advantage over a kio slave. I would think that a kio slave >> would be more natural, since users would not need to know terminology >> or the menu structure. > > Maybe I didn't use enough of the more fancy kio-slaves, but I have a > hard time imagining how I'd be able to use this with say konqueror. I'd > go to > > kscan:/// > > And then see whats been scanned, but how do I initiate a scan? Do I need > to go to some special url? If so, how do I trigger the OCR creation > after scanning? To activate a scan of an image, you either drag the image file in the kio slave to another folder, or you open it in a program (either by clicking or using the right-click menu). In the case of dragging it to a folder, it will be automatically scanned and saved in the destination folder without the user needing to do anything else. In the case where you open it in a program, it will probably be scanned to a temporary folder or stored in memory and then opened in the program, once again without the user doing anything else. In the case of OCR, it would be the same, except a temporary image file woulds be scanned, OCRed, and deleted (or again stored in memory). This, at least, is how the CD kio slave does it. -Odd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: GSoC idea: improving scanning and OCR in KDE (skanlite/kooka)
2012/3/7 Kåre Särs : > On Wednesday 07 March 2012 10:59:50 todd rme wrote: >> On Wed, Mar 7, 2012 at 10:46 AM, Andreas Pakulat wrote: >> > On 07.03.12 10:23:32, todd rme wrote: >> >> On Tue, Mar 6, 2012 at 8:03 PM, Klaas Freitag wrote: >> >> > On 06.03.2012 18:02, todd rme wrote: >> > [...] >> > >> >> > These kind of things. Not sure if a kio is cool for any of these. >> >> >> >> A gui able to do all the things you listed would necessarily be >> >> extremely complicated and likely difficult to use, unless most of the >> >> tasks were automated push-button affairs. In the latter case, there >> >> is little advantage over a kio slave. I would think that a kio slave >> >> would be more natural, since users would not need to know terminology >> >> or the menu structure. >> > >> > Maybe I didn't use enough of the more fancy kio-slaves, but I have a >> > hard time imagining how I'd be able to use this with say konqueror. I'd >> > go to >> > >> > kscan:/// >> > >> > And then see whats been scanned, but how do I initiate a scan? Do I need >> > to go to some special url? If so, how do I trigger the OCR creation >> > after scanning? >> >> To activate a scan of an image, you either drag the image file in the >> kio slave to another folder, or you open it in a program (either by >> clicking or using the right-click menu). In the case of dragging it >> to a folder, it will be automatically scanned and saved in the >> destination folder without the user needing to do anything else. In >> the case where you open it in a program, it will probably be scanned >> to a temporary folder or stored in memory and then opened in the >> program, once again without the user doing anything else. >> >> In the case of OCR, it would be the same, except a temporary image >> file woulds be scanned, OCRed, and deleted (or again stored in >> memory). >> >> This, at least, is how the CD kio slave does it. >> > > If somebody is interested in making such a kio slave, for simple usecases, I > would say go ahead and scratch your itch :) I do have a some doubts about the > usability tho. > > 1) You would have to "refresh" the view to get a new preview of new photos > placed on the scanner and the automatic photo finder is bound to fail > sometimes and you would be unable to select the correct part of the images. Yes, refreshing would be needed, both for this and for a standalone app. The issue with incorrectly detected borders would also affect a standalone app. Of course this is intended for simple jobs, anything complicated would need a more advanced app. But for most cases simple is enough. > 2) You have options (folders?) > - scan mode: grayscale, color > - resolution 50 100 150 300 600 1200 2400 4800 ... > - source: flatbed, automatic document feeder, transparency unit, ... > - how would you adjust gamma if available > - contrast/light... The only folders would probably be resolution, and one extra folder for the ADF if available. The ADF would primarily be useful for PDFs, TIFFs, and OCR, so in that folder could be individual files for OCR, PDFs at various resolutions, and TIFFs at various resolutions. Color vs. grayscale could have two images for the whole scan, so only one more file per resolution. OCR would handle that automatically, and scanned photos are unlikely to be in grayscale. Transparency units usually replace the main scan bed, so the could be detected as individual pictures and scanned that way. Gamma, contrast, lightness, etc would require a standalone app. > 3) Multipage scanning from ADF can not have a preview... No, but this is true in a standalone app as well. > For simple point and shoot it might work some of the time but I'm not sure the > amount of bug reports for heuristics failures would be fun to go through ;) The same bug reports would be needed for a standalone app, since it would be using the same defaults. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: A note about KIO and password management
On Fri, Apr 20, 2012 at 8:13 PM, Dawit A wrote: > Though this is documented in multiple places, it might not be apparent to a > lot of developers as I have encountered and addressed this issue in multiple > places recently. > > If you are using KIO in your application and you want user provided > credentials to be cached for the duration of your application, you need to > make sure you call KIO::JobUiDelegate::setWindow once you obtain an instance > of a KIO job. You set the main window through the KIO::JobUiDelegate > instance provided by KIO::Job itself (see KIO::Job::ui()): > > KIO::TransferJob* job = KIO::get(url); > job->ui()->setWindow(widget->window()); > > Unless you do that, any credential requested from the user will only be > cached for approx. 10 secs. When that time expires, the user will be > prompted to enter those credentials again. BTW, this also applies to other > classes like KDirLister as well. In case of KDirLister, you have to do the > following: > > KDirLister* lister = new KDirLister; > lister->setMainWindow(widget->window()); > > So, the next time a user complains about being required to login credentials > over and over again when using your application, check your code to make > sure it is doing the right thing. > > Regards, > Dawit A. Is there a situation where someone would want to cache credentials for only 10 seconds? If not, should there be a warning of even a build failure if a program tries to do that? Maybe a warning now and a failure under frameworks? If there is a need for caching credentials without a window perhaps a different API with finer-grained control of the caching would be better. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Several new utilities for KDE: KLook and StackFolder
On Thu, May 3, 2012 at 11:46 AM, Denis Koryavov wrote: > KLook > > KLook is an other utility for KDE, it written in QML. With the help of this > utility, user can quickly > look at files with different mime-types. In fact, it is practically exact > copy of MacOS X > QuickLook utility). User can use it directly from the Dolphin file manager > by pressing > a 'Space' key on keyboard. > In dolphin, you know the "+" button in the corner that you click to select the file? It would be nice if there was a button in another corner to trigger KLook. It would be much more convenient for people navigating with a mouse to not have to switch over to the keyboard. See here: http://forum.kde.org/viewtopic.php?f=83&t=38913&hilit=dolphin+corner -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Need some help with Dolphin
On Tue, Jun 12, 2012 at 9:03 AM, Mario Fux wrote: > Am Dienstag 12 Juni 2012, 07.54:24 schrieb Srikanth S: > > Morning Srikanth > >> Thanks for your response Sebastian. Apart from the possible problems you've >> mentioned, I see the following as well: >> 1. Many people would keep movies and such on external media - like external >> HDD. In that case, the analysis needs to be done on a on-need basis - when >> the HDD is connected. Even in that case, parsing through a 1TB HD to find >> and analyze movie files is not practical. >> 2. IMDb explicitly forbids storing the results (except for website caching) >> in any medium. So a static analyzer or cached results in any form is a >> strict no. >> >> Any other solutions? I was hoping that Dolphin APIs would allow for writing >> extensions like these. > > This could be of interest for you: > http://trueg.wordpress.com/2012/02/11/a-fun-release-nepomuk-tv-namer-0-2/ > > It's a Nepomuk solution to get meta information about tv series. > > griits > Mario Rather than that, you should look at nepomuk-metadata-extractor (see http://joerg-weblog.blogspot.de/2012/02/nepomuk-metadata-web-extraction.html ). In short, it is a plugin-based system to download metadata for arbitrary files from any arbitrary website based on plugins and load it into nepomuk. It should already be able to handle getting movie data from imdb. I don't think it automatically scans removable media, though, so you would probably need to implement that part of it. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Bugs for unmaintained applications
There seem to be open bugs for applications that appear to be unmaintained for a very long time (most since KDE 3 days or have been replaced by newer applications): kerry kandy Kwifimanager KSokoban kbfx systemsettings-kde3 Khalkhi kpdf ktip metabar ksayit kdetv kiconedit kugar dcop krecord lanbrowsing noatun kjsembed kghostview kcontrol kpackagekit So are these applications unmaintained, and if so should the bugs for these be closed as unmaintained? I guess, as a more general question, should bugs for all applications that were never ported to KDE 4 be closed as unmaintained? What about applications that have been replaced by other applications (kpackagekit, for example) Also, the list of components on bugs.kde.org has a ton of empty, unmaintained components besides these. Should those be hidden from the default list of components? Finally, it is still possible to submit bugs for these applications. Should they be hidden from the list of applications you can submit buts for? -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Call for testing: kio-mtp
On Fri, Sep 21, 2012 at 11:03 AM, Philipp Schmidt wrote: > Hi, > > thanks for the feedback! > > Am Freitag, 21. September 2012, 20:27:35 schrieb Ben Cooksley: >> Thanks for writing this - it makes using an Android device >> significantly easier I must say. >> It worked perfectly fine with the Android tablet I tested it with. > > Perfectly is not the word I'd use, there are still plenty of things to do, > some random crashes and slow Operation when copying lots of small files to > name the two most severe ones. The first I am still investigating, for the > second I am already working on a solution. So copying lots of small Photos for > example should be much smoother in a follwing revision. > > Alex Fiestas and I are also working on integrating it more closely with the > Device Notificator. So hopefully later this year you can open Dolphin on the > device right from there. > > Cheers, > Philipp Does this depend on master or can it run on KDE SC 4.9? -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Call for testing: kio-mtp - Updated repo
On Tue, Oct 2, 2012 at 7:53 AM, Philipp Schmidt wrote: > If you haven't found out already, the Slave is now in playground. > > https://projects.kde.org/projects/playground/base/kio-mtp > > Please use this to check it out of git: > > git clone git://anongit.kde.org/kio-mtp > > Philipp One minor issue: cmake checks for libmtp, and checks the version, but it still tries to build below the minimum version (and fails), and it doesn't tell you what the minimum version is (I had to check in the cmake file). -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Nepomuk] Nepomuk - Moving away from Strigi
On Mon, Oct 8, 2012 at 3:51 PM, Vishesh Handa wrote: > Hey everyone > > For 4.10, Nepomuk will no longer depend on Strigi for file indexing. We have > written our own file indexer which are based on popular libraries such as > taglib, exiv, ffmpeg, etc. This allows us to better control the indexing > process. If you would like to know more reasons as to why the change was > done, please read [1]. > > I will be merging this new file indexing code into master by the end of the > week. > > @ Packagers: > > I talked with Will Stephenson (OpenSuse) a couple of weeks back, and he > informed me that it might be problematic for distributions to ship > nepomuk-core if it depends on ffmpeg, taglib, and other packages which are > slightly controversial. Is this going to be a problem? He suggested that the > file indexing plugins be present in a separate repository. It doesn't affect > us much, so I would like to know your opinion? Do you want it to be in a > separate repo? > > [1] http://mail.kde.org/pipermail/nepomuk/2012-September/003167.html > > -- > Vishesh Handa What do you mean by "separate repository"? Do you mean people would be able to build and install the plugins independently of nepomuk-core? Certainly for the legally questionable ones this would be nice. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Nepomuk] Nepomuk - Moving away from Strigi
On Mon, Oct 8, 2012 at 4:42 PM, Vishesh Handa wrote: > > > On Mon, Oct 8, 2012 at 8:08 PM, Eric Hameleers wrote: >> >> On Mon, 8 Oct 2012, Aleix Pol wrote: >> >>> In any case, I'm unsure that KDE can shine without ffmpeg. >>> >>> Aleix >>> >> >> I am sure that ffmpeg is providing some core functionality here. But, a >> distribution like Slackware does not ship a system "ffmpeg" package. This is >> done for various reasons, an important reason being that it will make it >> near impossible to upgrade the system ffmpeg package. It is extremely easy >> to break packages by upgrading a shared ffmpeg library they are depending >> on. For that reason alone, we prefer to ship applications with an embedded >> statically compiled copy of ffmpeg when they need it. >> >> Having hard requirements on ffmpeg for your nepomuk indexer would not be >> appreciated by us. Making ffmpeg an optional dependency would be better (but >> will cripple the indexer seriously). I think the best solution would be to >> allow for an optional static binding of ffmpeg libraries. > > > That is the current scenario. All indexing plugin (including ffmpeg) are > optional during compile time. > > The only question is - Should the code be present in nepomuk-core or a new > repository. Out of curiosity, what is the functionality that depends on ffmpeg? I am not sure it is really possible to know the best approach unless we know what we are losing by not having it. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
