Re: Forward-ports in kde-workspace
On Sunday, February 6, 2011, you wrote: > Additionally, the following commit was partially backported (in > r1214728); only the addLauncher call was changed, and not the > connect/disconnect calls: > > commit 120064d95e890eeb8f748e641aa0c3ea13aef4c2 > Author: Aaron J. Seigo > Date: Sat Jan 15 23:11:15 2011 + > > don't supress the signal, just disconnect/connect to it > > svn path=/trunk/KDE/kdebase/workspace/; revision=1214696 the signals were removed in trunk/master; this is why the backport/forwardport (whichever direction :) was different. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Forward-ports in kde-workspace
Here is a list of commits in kde-workspace:4.6 that seem to be missing a forward-port into master. I don't claim correctness of this list; please let me know if there's something wrong in it. I'm posting this so that devs do their forgotten forward-ports before the 4.6->master git merge is attempted. Which doesn't mean I'm asking you to do anything; this is raw information, take your own conclusions and decisions from it :) There are some commits where it's obvious why they *shouldn't* be in master, but I'm including them for completeness (as there's also many where there may be an obvious reason but not obvious to me). commit 890726e447b7285ba3ccab690fb29a443eed95db Author: Davide Bettio Date: Fri Dec 24 13:55:02 2010 + I have to move Ethais to kdeartwork due the 15 wallpapers rule. svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1209083 commit 7490e103b3b204fcf095ad1abf766a484ab68730 Author: Jacopo De Simoi Date: Mon Jan 3 15:21:31 2011 + Treat remote NFS/CIFS shares as non-removable devices This is just a hack valid for the 4.6 timeframe, and should *not* be forwardported to trunk. CCBUG: 259345 CCBUG: 259740 svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1211298 commit ac1c759c74dd0c1b6579b0a05b410be2cd2e660e Author: Dirk Mueller Date: Tue Jan 4 13:51:54 2011 + bump version svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1211566 commit 5154020619bb462d9f16826389774208353edb54 Author: Thomas Lübking Date: Wed Jan 5 14:44:54 2011 + remove qdebug leftover svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1212026 commit b9c9b541167916e6cb76e1ad8b70a02b40542c38 Author: Dirk Mueller Date: Mon Jan 17 22:00:26 2011 + KDE 4.6.0 preparations svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1215169 commit 1d4bc4d8a769c7b8eaf3395dc1bb4ab9489bf7fb Author: Alexander Potashev Date: Wed Jan 19 16:06:43 2011 + SVN_SILENT Manually translate strings in .desktop files into Russian for 4.6.0 release svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1215769 commit a443f541fb68ac4d83902ba0236570b8802562a2 Author: Dirk Mueller Date: Thu Jan 20 21:59:05 2011 + disable krunner integration by default to workaround the impact for most of the users with bug#246678 svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1216031 commit 607831437d9dba99aa1a54065586257d7f00c340 Author: Andriy Rysin Date: Sat Jan 22 19:16:33 2011 + Restore old DBus API: org.kde.kxkb back as an alternative and print deprecation warning if used BUG: 263006 svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1216339 commit a6d1e5e1397555b317c84fe4e3266e6892074bf6 Author: Will Stephenson Date: Wed Jan 26 14:25:13 2011 + Remove MALLOC_CHECK_ from 4.6 branch CCMAIL: release-t...@kde.org CCMAIL: kde-packa...@kde.org svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1217284 commit 375112824488df9a827a498b512eabeb5ce0deaf Author: Hugo Pereira Da Costa Date: Thu Feb 3 11:44:59 2011 +0100 Check validity of QToolButton cast before testing popupMode() BUG: 265271 commit 2e4563e92116502c119dfcf7a340545eeaf182df Author: David Faure Date: Sat Feb 5 10:45:10 2011 +0100 Calling deleteLater on NULL gives "QCoreApplication::postEvent: Unexpected null receiver" commit 17934f79fa691a52efc4df142e5e8712634ad21a Author: Thomas Lübking Date: Fri Feb 4 21:27:27 2011 +0100 explicitly trigger minimal repaint on property change, otherwise broken when switching windows commit 04831d049f73bb38694d7cecc4ea170b2a26a149 Author: Thomas Lübking Date: Fri Feb 4 21:28:31 2011 +0100 remove delted windows from list. can happen and triggers kwin part of BUG: 265297 commit c640d3a60241fbf4d53608db318acf260e5956be Author: Andriy Rysin Date: Sat Feb 5 15:33:00 2011 -0500 fix layout map when using indicator mode BUG: 264595 Additionally, the following commit was partially backported (in r1214728); only the addLauncher call was changed, and not the connect/disconnect calls: commit 120064d95e890eeb8f748e641aa0c3ea13aef4c2 Author: Aaron J. Seigo Date: Sat Jan 15 23:11:15 2011 + don't supress the signal, just disconnect/connect to it svn path=/trunk/KDE/kdebase/workspace/; revision=1214696 -- Nicolas
Re: Epseranto flag
A Diumenge, 6 de febrer de 2011, Andriy Rysin va escriure:
> On 02/06/2011 07:15 AM, Albert Astals Cid wrote:
> > A Dissabte, 5 de febrer de 2011, Andriy Rysin va escriure:
> >> I have this "Add the Esperanto flag (please)" but
> >> (https://bugs.kde.org/show_bug.cgi?id=264533) and I don't feel like this
> >> flag belongs to just keyboard indicator. So the question is whether we
> >> have or should have Esperanto flag somewhere in common place?
> >
> > http://l10n.kde.org/stats/gui/trunk-kde4/team/
> >
> > Not that is of course any kind of canonical place for flags.
>
> Well, I am a bit confused, are you suggesting to fetch flag from the web
> in system settings, i.e. something like
> QImage flag("http://l10n.kde.org/img/flags/eo.png";);
No, i'm just saying that we already use the Esperanto flag in some other
place, so it should not be a problem for you using it.
Albert
> ? :)
>
> Andriy
Re: git clone kde:kde-workspace hangs
On Sunday, 6 de February de 2011 16:48:21 Shaun Reich wrote: > On Sun, Feb 6, 2011 at 4:30 PM, Martin Koller wrote: > > Hi, > > > > I've tried already several times today to get a clone of kde-workspace > > and it always gets stuck at about 10-15% > > > > What can I do ? > > You can try using the tarball form on project.kde.org, for now (no idea why > it hangs up). at least then you can resume it. Note that the git clone/fetch/push percentage is by number of objects, not size. I have tried cloning kde-workspace now and it worked fine, but I did notice a slowdown around 14-15%. My guess is that there are some big objects being transferred. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: git clone kde:kde-workspace hangs
On Sun, Feb 6, 2011 at 4:30 PM, Martin Koller wrote: > Hi, > > I've tried already several times today to get a clone of kde-workspace and > it always gets stuck at about 10-15% > > What can I do ? > You can try using the tarball form on project.kde.org, for now (no idea why it hangs up). at least then you can resume it. -- Shaun Reich, KDE Developer (www.kde.org)
git clone kde:kde-workspace hangs
Hi, I've tried already several times today to get a clone of kde-workspace and it always gets stuck at about 10-15% What can I do ? -- Best regards/Schöne Grüße Martin () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: Epseranto flag
On 02/06/2011 07:15 AM, Albert Astals Cid wrote:
A Dissabte, 5 de febrer de 2011, Andriy Rysin va escriure:
I have this "Add the Esperanto flag (please)" but
(https://bugs.kde.org/show_bug.cgi?id=264533) and I don't feel like this
flag belongs to just keyboard indicator. So the question is whether we
have or should have Esperanto flag somewhere in common place?
http://l10n.kde.org/stats/gui/trunk-kde4/team/
Not that is of course any kind of canonical place for flags.
Well, I am a bit confused, are you suggesting to fetch flag from the web
in system settings, i.e. something like
QImage flag("http://l10n.kde.org/img/flags/eo.png";);
? :)
Andriy
Re: Review Request: New KIO::http_post and KIO::StoredHttpPost APIs that accept a QIODevice as input...
On Fri, Feb 4, 2011 at 12:25 PM, Allan Sandfeld Jensen wrote: > On Friday 04 February 2011, Thiago Macieira wrote: > >> Em sexta-feira, 4 de fevereiro de 2011, às 16:52:54, Allan Sandfeld Jensen > >> > >> escreveu: > >> > Or to put another way; PUT takes a KUrl to send to and gets the data it > >> > sends from a slot. POST is essentially just a PUT with return data, so I > >> > would find it most natural if POST mirrored PUT in how it sends data >> > just > >> > like it mirrors GET in how it receives it. > >> > >> A PUT-from-GET operation is called "copy" and we already have that > >> operation: KIO::file_copy. > >> > >> A streaming POST is not a common case, though, because POSTs most often > >> require a -like transport or, in the case of SOAP, XML. > > Well. The short the form-like posts are not a problem. The point was to fix > big posts. > > I am not sure it is important, but POST is often misunderstood, it is not > like copy at all. From an abstract point of view it is a translation. You > send something to a place and get something else in return. > > GET: url -> data > > PUT: data -> url > > Copy: url -> url > > POST: data -> url -> data > > In KIO get and put has been implemented like: > > GET: url -> stream of data > > PUT: stream of data-> url > > But POST still required data upfront: > > POST: data -> url -> stream of data > > The case we are trying to solve is not having data be concrete data, but > instead a source of data. > > So somekind of > > POST: stream of data -> url -> stream of data > > Again. I am not sure such a solution is necesary. I just felt it was a > suggestion that should be made, because it would make the architecture.. > Well, more pleasing in my mind ;) I concur with everything you stated above, but I fail to see why these new APIs would be better if they took KIO job instead of QIODevice. How would the client use that API ? It would have to create a KIO job with the post data first, but what kind of job would that be ? It would then have to use yet another job to post the data ? Is that not a bit more convoluted ? Perhaps I misunderstood your entire suggestion. On the other hand I think I get the KUrl parameter idea if it meant that the client app will have to create the encoded data to POST/PUT to the remove server, e.g. a temporary file, and provides that URL to the job. The key word here being that it must do the necessary encoding itself even when the request is to simply upload a bunch of files to a server. Was that the idea ? If so, I do not see why that could not be done in addition to these two new APIs either. Regards, Dawit A.
Re: svn-merge.py and git
A Domingo, 6 de Fevereiro de 2011 14:55:18 Martin Gräßlin você escreveu: > On Sunday 06 February 2011 15:47:05 Arno Rehn wrote: > > On Sunday 06 February 2011 14:13:57 Hugo Pereira Da Costa wrote: > > > my idea at that > > > time was that oxygen-transparent would get merged back to trunk/master > > > at some point, but this will not happen > > > > Slighty off-topic, but why's that? I've always looked forward to seeing > > oxygen-transparent being officially in kdebase. > > Probably two reasons: > 1. Nuno does not want it > 2. I don't want it, as KWin is not optimized for the everything is > translucent and blurred use case. (That also applies for all other > translucent widget styles you can find: don't use them if you want a > fast/usable system!) > > Cheers > Martin Before I turn Into the evil dictator I am :) its not that I have anything againts oxygen trasparent Its just that i dont think that From a design prespective its still oxygen Plus i think a difrent theme can do that way way better +given all the ways one could brake" apps by using it i think it's not ment for defoult land, wich in a way could be good as we could test maore crazy ideas in such a theme... -- oxygen guy, "I make the pretty pictures"
Re: Review Request: Prevent KHTML's adblock filter parser from incorrectly parsing rules with options...
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100572/ --- (Updated Feb. 6, 2011, 4:07 p.m.) Review request for kdelibs. Summary --- This request is created because no one from the KHTML developerment team responded to my post in kfm-devel. Basically this patch prevents the FilterSet::addFilter function in khtml_filter.cpp from incorrectly interpreting a rule with options such as *$image,~image,donottrack as the wildcard matching "*". Obviously doing that causes every request processed to be matched and hence blocked. The above rule was extracted from a recent version of Easy Privacy + EasyList filter. Here the relevant snippet: [Adblock Plus 1.1] ! Checksum: BjTRSfga8mRDTYGW3UpIDQ ! EasyPrivacy and EasyList combination subscription ! Last modified: 29 Jan 2011 18:30 UTC ! ! *** easyprivacy.txt *** ! EasyPrivacy - https://easylist.adblockplus.org/ ! Expires: 5 days (update frequency) ! Licence: https://easylist-downloads.adblockplus.org/COPYING ! ! Please report any unblocked tracking or problems ! in the forums (http://forums.lanik.us/) ! or via e-mail (easylist.subscript...@gmail.com). ! !-The X-Do-Not-Track header-! *$image,~image,donottrack < RULE THAT CAUSES THE PROBLEM !-General tracking systems-! ! *** easyprivacy/easyprivacy_general.txt *** If you do not have this patch and you activate adblocking with the EasyPrivacy + Easy List filter selected, then the images will be missing when Konqueror's default page (about:konqueror) is shown. Diffs - khtml/khtml_filter.cpp dc3d0f50b Diff: http://git.reviewboard.kde.org/r/100572/diff Testing (updated) --- Tested by applying the patch and seeing that Konqueror correctly renders the default about page. Thanks, Dawit
Re: Top 15 Mailinglists with messages in moderation
- Original Message - > 20 kde-embedded The maintainers email (p...@kde.org) is bouncing. Do we need this list? I see almost no activity for the last months.. Best, -- Tom Albers KDE Sysadmin
Re: Top 15 Mailinglists with messages in moderation
- Original Message - > On Tuesday 01 February 2011 13:45:27 George Goldberg wrote: > > >> 41 kdelibs-bugs > > > > This is a very useful list for bug triagers - I can volunteer to > > moderate it if no-one else is currently doing it. > > ditto, if more than 1 or 2 mods are needed. Added. Thanks! -- Tom Albers KDE Sysadmin
Re: Top 15 Mailinglists with messages in moderation
- Original Message - > >> 41 kdelibs-bugs > > This is a very useful list for bug triagers - I can volunteer to > moderate it if no-one else is currently doing it. > > > > >> 29 plasma-bugs > > Same as kdelibs-bugs for this one. Done for both. Thanks for volunteering! -- Tom Albers KDE Sysadmin
Re: Top 15 Mailinglists with messages in moderation
- Original Message - > On Tuesday 01 February 2011 13:01:32 Tom Albers wrote: > > 29 kde-java > I think we can safely delete that one. We don't have Java bindings > anymore and > the main bindings ML is kde-bindings. A quick glance at those mails > would > still be cool (can I somehow view them?). It was only spam, facebook and linkedin friend requests, and up to 80% discount on some medicine. I've deleted the list. Best, -- Tom Albers KDE Sysadmin
Re: Top 15 Mailinglists with messages in moderation
Ok. Thanks for that. kmobiletools has been removed now. Best, Toma - Original Message - > Hi, > > > I've talked to current maintainer (Quentin Denis) about this. And this > is his response: > "anything related to KMT can be removed, the code is now pure > playground I dont need that mailing list." > So I guess one can remove it. > > > Cheers, > Dinesh > > > > > > > On Wed, Feb 2, 2011 at 4:37 AM, John Layt < johnl...@googlemail.com > > wrote: > > > On Tuesday 01 February 2011 13:45:27 George Goldberg wrote: > > >> 41 kdelibs-bugs > > > > This is a very useful list for bug triagers - I can volunteer to > > moderate it if no-one else is currently doing it. > > ditto, if more than 1 or 2 mods are needed. > > John. -- Tom Albers KDE Sysadmin
Re: svn-merge.py and git
On Sunday 06 February 2011 14:13:57 Hugo Pereira Da Costa wrote: > my idea at that > time was that oxygen-transparent would get merged back to trunk/master at > some point, but this will not happen Slighty off-topic, but why's that? I've always looked forward to seeing oxygen-transparent being officially in kdebase. -- Arno Rehn a...@arnorehn.de
Re: svn-merge.py and git
On Sunday 06 February 2011 15:47:05 Arno Rehn wrote: > On Sunday 06 February 2011 14:13:57 Hugo Pereira Da Costa wrote: > > my idea at that > > time was that oxygen-transparent would get merged back to trunk/master at > > some point, but this will not happen > > Slighty off-topic, but why's that? I've always looked forward to seeing > oxygen-transparent being officially in kdebase. Probably two reasons: 1. Nuno does not want it 2. I don't want it, as KWin is not optimized for the everything is translucent and blurred use case. (That also applies for all other translucent widget styles you can find: don't use them if you want a fast/usable system!) Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: svn-merge.py and git
On Sunday 06 February 2011 15:47:05 Arno Rehn wrote: > On Sunday 06 February 2011 14:13:57 Hugo Pereira Da Costa wrote: > > my idea at that > > time was that oxygen-transparent would get merged back to trunk/master at > > some point, but this will not happen > > Slighty off-topic, but why's that? I've always looked forward to seeing > oxygen-transparent being officially in kdebase. Slightly off-topic indeed :) Reasons are: - kwin is not yet ready to support fully transparent windows (and notably its blur pluggin), - oxygen-transparent breaks many apps (notably most video players), and therefore needs a blacklist, which is not up to the standards of official KDE - design wise, oxygen's designers (well Nuno, to name people), don't believe that transparency should be part of the official oxygen, branding-wise. Since the dev (me) does (mostly) agree with all three items above, the matter is settled :)
Re: svn-merge.py and git
- Original Message - > On Sunday 06 February 2011 14:00:38 Artur de Souza wrote: > > Hi Hugo! > > > > Quoting Hugo Pereira Da Costa : > > > How can I achieve the same now that official oxygen is in git (in > > > kde-workspace) > > > ? > > > > I don't know the best way of doing this between svn and git. If > > everything was in git I would say that the best shot would be to > > have > > it in a branch and keep rebasing your branch with master. If you > > make > > this branch public then you would keep merging the branch with > > master. > > > > I considered that, and that would really be the easiest, but ... > - I want people to be able to download (and possibly packagers to > package) the > fork > > - in order to do that I actually renamed the pluggin names to oxygen- > transparent (and the style/deco to "Oxygen Transparent"). > This was not the case in the past (where oxygen-transparent would > simply > overwrite your official oxygen, but thats really not good (my idea at > that time > was that oxygen-transparent would get merged back to trunk/master at > some > point, but this will not happen). > > now I don't think you want a "branch" of official code that installs > pluggins > with different names ... and different libraries, etc. Can't you do this with a clone? Best, -- Tom Albers KDE Sysadmin
Re: svn-merge.py and git
On Sunday 06 February 2011 14:00:38 Artur de Souza wrote: > Hi Hugo! > > Quoting Hugo Pereira Da Costa : > > How can I achieve the same now that official oxygen is in git (in > > kde-workspace) > > ? > > I don't know the best way of doing this between svn and git. If > everything was in git I would say that the best shot would be to have > it in a branch and keep rebasing your branch with master. If you make > this branch public then you would keep merging the branch with master. > I considered that, and that would really be the easiest, but ... - I want people to be able to download (and possibly packagers to package) the fork - in order to do that I actually renamed the pluggin names to oxygen- transparent (and the style/deco to "Oxygen Transparent"). This was not the case in the past (where oxygen-transparent would simply overwrite your official oxygen, but thats really not good (my idea at that time was that oxygen-transparent would get merged back to trunk/master at some point, but this will not happen). now I don't think you want a "branch" of official code that installs pluggins with different names ... and different libraries, etc. > I know I didn't help much, but.. :P > > Cheers, > > Artur > > ---
Re: svn-merge.py and git
Hi Hugo! Quoting Hugo Pereira Da Costa : How can I achieve the same now that official oxygen is in git (in kde-workspace) ? I don't know the best way of doing this between svn and git. If everything was in git I would say that the best shot would be to have it in a branch and keep rebasing your branch with master. If you make this branch public then you would keep merging the branch with master. I know I didn't help much, but.. :P Cheers, Artur ---
Re: Epseranto flag
A Dissabte, 5 de febrer de 2011, Andriy Rysin va escriure: > I have this "Add the Esperanto flag (please)" but > (https://bugs.kde.org/show_bug.cgi?id=264533) and I don't feel like this > flag belongs to just keyboard indicator. So the question is whether we > have or should have Esperanto flag somewhere in common place? http://l10n.kde.org/stats/gui/trunk-kde4/team/ Not that is of course any kind of canonical place for flags. Albert > And all the flags we have currently belong to countries so I am not even > sure where it would belong. > > Thanks > Andriy
svn-merge.py and git
Hello all, another question about git. Some time ago, I "forked" oxygen to playground/artwork/oxygen-transparent in order to have a version of oxygen that supports ARGB windows and transparency. I was keeping the source in sync with official oxygen (cause the amount of changes needed for this ARGB support is quite small and well compartimented) by using svnmerge.py script, which obviously does not work since we moved to git. That was easy and working well. How can I achieve the same now that official oxygen is in git (in kde-workspace) ? Detailed instructions would be prefered, since everything i have tryed so far (git format-patch mostly), has failed miserably. (my fear is that in the impossibility to do that, the fork will slowly die, by getting out of sync with oxygen transparent, and withing a few month it will basically not be supported any more). Thanks in advance, Hugo PS: I also plan, at some point to move oxygen-transparent from svn to git.
Re: git won't let me delete a branch?
On 5 February 2011 20:39, Stefan Majewsky wrote: > Don't we have this yet? I'm using exactly this approach for my work > branches in libtagaro (cf. kde:libtagaro and > kde:clones/libtagaro/majewsky/work). The only fear I'm having is that > I'll once run into this 100-commits-per-push-operation limit. Btw, you know about squashing commits right? If you have a commit that you haven't pushed upstream, then a later commit which fixes a problem in the first commit, then you should do "git rebase -i origin" and reorder the commits and make one commit as to be squashed into the previous commit, so that you end up with a single commit. (You might already know, but I want to throw out tips for other people as well). John
