'2009-05-29 20:32:54' 'Justin Dolske' MattN noticed a problem with the WIP patch from bug 469443 applied. When typing in the search box, sometimes search-suggestion entries would be displayed above the divider (where entries for previous matching searches are). The problem here is that nsSearchSuggestions.js is passing the wrong previousResult to form history. Instead of it being the previous form history search result, it's the SuggestAutoCompleteResult result (which contains the union of the form-history and search-suggest entries). So, when form history refines its results as you time, it can actually add *more* entries as data leaks from the suggestions result into form history result, and it thus looks like the divider is being drawn in the wrong place. This bug wasn't visible before 469443, because nsFormFillController::StartSearch tries to QI the provided result to a nsIAutoCompleteSimpleResult. The search-suggestion result is only implements nsIAutoCompletResult (no \"Simple\"), so the QI fails, historyResult nee previousResult becomes null, and thus Satchel was doing a new search every time. EG: 1) type \"b\" in the search field. 2) form history finds 1 entry (\"blah\"), search-suggestions finds \"baaa\", \"bloop\", \"bzzz\", the autocompete menu shows these in order with a divider between \"blah\" and \"baaa\". 3) type an \"l\" in the search field (\"bl\") 4) startHistorySearch()'s previous result contains [\"blah\", \"baaa\", \"bloop\", \"bzzz\"], Satchel filters this down to [\"blah\", \"bloop\"] to match the new \"bl\" search string 5) nsSearchSuggestions's onReadyState() change is called with updated search suggestions, builds up a new list of results, but sees that the form history result now has *two* entries. '2009-05-29 20:37:31' 'Justin Dolske' Created an attachment (id=380567) [details] Patch v.1 (WIP) This fixes the problem, but isn't quite correct... If you type \"a<backspace>b\", satchel trying to use the results from the \"a\" search for the \"b\" search, and so nothing is found. I suspect nsSearchSuggestions needs to throw away the old form history result when the search string changes like this, but I'm not entirely sure it's responsible for doing so, maybe satchel should be smarter about throwing away a previous result when the previous result's search string doesn't have a common prefix. [That seems to be handled somewhere else for normal form field entries, oddly enough.] '2009-06-14 18:55:25' 'Justin Dolske' Created an attachment (id=383211) [details] Patch v.2 Ah. So, there's a ._formHistoryResult in the SuggestAutoCompleteResult wrapper (used to combine form history with search suggestions), and also a ._formHistoryResult in SuggestAutoComplete (the service itself, used to hold onto a form history result until a search suggestion is available). The simple fix it to just discard the service's form history result copy when startSearch() is called with a null previous result. Otherwise it's trying to use a old form history result that no longer applies for the search string. '2009-06-19 12:07:34' 'Gavin Sharp' (From update of attachment 383211 [details]) Perhaps we should rename one of them to _fhResult just to reduce confusion? '2009-06-19 13:17:56' 'Justin Dolske' (In reply to comment #3) > (From update of attachment 383211 [details] [details]) > Perhaps we should rename one of them to _fhResult just to reduce confusion? Good point. I renamed the one in the wrapper to _formHistResult. fhResult seemed maybe a bit too short. '2009-06-19 13:20:52' 'Justin Dolske' Pushed http://hg.mozilla.org/mozilla-central/rev/097598383614 '2008-08-07 07:22:12' 'Simon Bunzli' That pref was thought to be for extensions which wanted to completely replace our own Session Restore functionality. While this has worked somehow for Tab Mix Plus, we've had several issues with people ending up both Session Restore and Tab Mix Plus disabled (see bug 435055 and its duplicates). Furthermore, there are several code points which will also break when Session Restore has been disabled (such as the list of recently closed tabs). Instead of adding try-catch-blocks wherever we use Session Restore, I'd much rather encourage extensions authors to override both nsSessionStartup and nsSessionStore to provide the same API with their own functionality (or implementing a dummy-API and making sure for themselves that they've correctly replaced all known consumers). This would also make the lives of those other extension authors simpler who so far can't be too sure that the Session Store component actually works (through whatever implementation). Note that privacy concerned users will still be able to disable writing to sessionstore.js through the browser.sessionstore.resume_from_crash pref. '2008-08-07 07:42:37' 'Simon Bunzli' Created an attachment (id=332726) [details] remove the pref '2008-08-13 11:37:55' 'Nickolay Ponomarev ' (note: bug 448725 should be wontfixed if this is fixed) '2008-08-14 14:08:24' 'Simon Bunzli' Created an attachment (id=333820) [details] remove (buggy) note from API comments '2008-08-18 14:33:16' 'Dietrich Ayala' (From update of attachment 332726 [details]) a problem with this patch is that the session data is still stored in memory while the app is running, and by removing this pref, there's no way to disable that. some users do not want the recently-closed-tabs menu, and others don't want any session tracks stored in memory at all. '2008-08-18 14:46:25' 'Simon Bunzli' (In reply to comment #4) > some users do not want the recently-closed-tabs menu, That's what browser.sessionstore.max_tabs_undo is for: setting it to 0 effectively disables the feature. > and others don't want any session tracks stored in memory at all. Then again, we don't save any data that wouldn't be in memory, anyway, or do we? I'd rather introduce a different pref or different means to cater the privacy sensitive users than have this half-baked cut-it-all pref which AFAICT so far has produced more issues than it's solved. '2008-08-19 10:07:17' 'Dietrich Ayala' (In reply to comment #5) > Then again, we don't save any data that wouldn't be in memory, anyway, or do we? Fair point. I'm not sure. > I'd rather introduce a different pref or different means to cater the privacy sensitive users than have this half-baked cut-it-all pref which AFAICT so far has produced more issues than it's solved. Yes, agreed the pref is not ideal for this purpose. So max_tabs_undo=0 + resume_from_crash=false is fine for now, until proper \"private browsing\" is supported. '2008-08-19 10:12:56' 'Dietrich Ayala' (From update of attachment 332726 [details]) >+ // XXXzeniko should't we just disable this item as we disable >+ // the tabbrowser-multiple items above - for consistency? >+ this.mUndoCloseTabMenuItem.hidden = >+ Cc[\"@mozilla.org/browser/sessionstore;1\"]. >+ getService(Ci.nsISessionStore). >+ getClosedTabCount(window) == 0; +1 r=me '2008-08-19 10:22:13' 'Simon Bunzli' (In reply to comment #7) > +1 That's bug 350731. Care to convince mconnor that he's wrong? ;-) '2008-08-19 22:49:19' 'Reed Loden' Pushed as 17120:e712e96d7861 and 17121:adb1ef78dd21. '2008-08-20 02:15:09' 'Simon Bunzli' onemen: This patch significantly affects Tab Mix Plus: Instead of disabling SessionStore, you'll now have to replace it by shipping a component which implements the same API. You should be able to keep that component minimal, though, and just call your own code whenever the API is used. This will make the lives of people using the SessionStore API (such as Session Manager) somewhat simpler, as they can just use the API without having to worry too much about the implementation behind it. If you want to offer the option of switching between your and our implementation, see e.g. the ignore-history component of the Torbutton extension for how to overwrite a component with the original still being available internally (so that you can either pass API calls forward or handle them yourself). '2008-08-20 09:46:40' 'Dave Townsend' Sounds like this has impact for extension authors and so should be documented on MDC '2008-08-20 10:10:49' 'onemen' no problem. current Tabmix dev-build already not disable SessionStore I currently have only one problem , how to disable the restore after restart. can you add a pref for this, or some other way to do it? '2008-08-20 11:04:03' 'Simon Bunzli' (In reply to comment #12) > I currently have only one problem , how to disable the restore after restart. You've got several options for that: * Set the prefs browser.sessionstore.resume_from_crash and browser.sessionstore.resume_session_once both to false as early as possible and make sure that browser.startup.page isn't 3. * Delete the file sessionstore.js as early as possible (e.g. when the profile-after-change notification is dispatched). * For Firefox 3.1: Respond to the sessionstore-state-read notification by setting the subject's data member to an empty string (cf. bug 448741 comment#6). Or is there a use case I'm missing? '2009-05-07 13:09:47' 'Justin Dolske' I've noticed that I frequently trigger the rotate gesture accidentally, usually while scrolling. Gestures have improved since the original landing (when triggering the wrong gesture was really easy), but this articular gesture is still problematic. The basic reasoning is that it's highly disruptive to be switched to another tab when you're not expecting it. When it happens, you don't know what just happened until you notice that you're on some entirely different page, that's randomly to the left or right (1 or more tabs) from the page you thought you were on. I'm don't think the rotate gesture for switching tabs is nearly as useful, discoverable, or a good fit as the other gestures are. So, given this problem, we should just disable it for 3.5. [I'd also be open to tweaking it to make it much harder to trigger accidentally, dunno if that's possible.] '2009-05-07 13:20:26' 'Henrik Skupin' See also bug 461376. Just play around with browser.gesture.twist.* in about:config as a temporary workaround. '2009-05-07 14:11:45' 'Mike Beltzner' Justin, the odd thing here is that I find I trigger zoom more frequently than tab rotate ... far far more frequently. And I also find that it's not just in Firefox, it's all over OSX. I wonder how much of this is us vs. odd timings causing misreads of the trackpad by OSX. '2009-05-07 15:03:52' 'Olli Pettay' I think I've never accidentally switched tab because of rotate gesture. Actually I'd probably decrease the default threshold for tab switching. '2009-05-07 16:02:51' 'Justin Dolske' I've triggered zoom repeatedly too; usually I fix it right away but a quick browse though content-prefs.sqlite shows ~20 sites with zoom settings that I didn't know were set. That's probably because zoom is a subtle effect (for 1 step, relative to the distraction that an accidental tab switch causes). While playing with different browser.gesture.twist settings, I've found twisting through tabs often resulted in triggering a zoom. Probably because a twist is a very awkward gesture to make, especially if it's more than a quarter-turn... Around that point, my fingers want to spread or join, and that ends up read as a pinch. I guess that's part of why I'm not really fond of this gesture, and would just as soon turn it off. I'll try running with a threshold of 40, but I suspect there's an unavoidable conflict between making it easy to use on purpose, yet hard to invoke accidentally. '2009-05-07 16:08:28' 'Edward Lee' I've been using swipe left/right to change tabs and cmd-left/right to go back/forward, but I do have rotate as change tabs as well and I haven't accidentally triggered it. Maybe it's your rotating technique ;) I'm right handed and I position my index finger at 7oclock and ring finger at 1oclock. To rotate right I end up at 8/2oclocks. '2009-05-07 16:10:08' 'Samuel Sidler' The first time I came into contact with tab switching via gesture was accidentally. I wasn't sure what happened, I just appeared on another tab and couldn't figure out why. The tab-switching gesture right now isn't obvious and feels unexpected when I hit it. '2009-05-11 07:00:44' 'Mike Beltzner' Mardak: the way you've written this code, disabling the gesture is a pref-flip, right? Blocking here for decision and mulling, will probably take it though. '2009-05-11 08:38:06' 'Edward Lee Mardak' Yup, should be able to just unset the default value for the twist prefs: -pref(\"browser.gesture.twist.right\", \"Browser:NextTab\"); -pref(\"browser.gesture.twist.left\", \"Browser:PrevTab\"); '2009-05-11 10:45:51' 'Justin Dolske' Would setting the value to empty-string (\"\") work, or something similar? It would be nice to leave the prefs visible for those who want to use them. '2009-05-11 12:24:05' 'Robert Strong' Since this is now implemented on Win7 with Multitouch screens please be sure not to disable it for Windows. '2009-05-11 14:54:42' 'Justin Dolske' (In reply to comment #10) > Since this is now implemented on Win7 with Multitouch screens please be sure not to disable it for Windows. Fine by me; though I'd be a bit wary of having Windows users hit the same problem with multitouch trackpads... But Rob says such hardware/drivers doesn't exist today, so it shouldn't be a common problem. We should keep on eye out for problems with issues on touchscreens, andt from Rob demoing it on his touchscreen it would appear harder to trigger. And maybe Windows 7 is just better at discriminating between gestures. OTOH it wouldn't be a big deal to just disable it globally. Safari doesn't use it, and Rob confirmed that IE doesn't use it on Windows 7. '2009-05-11 15:00:31' 'Edward Lee Mardak' This bug is just rotate, but do we want to consider pinching too? If we take those out, we'll have swipe up/down as jump to top/bottom and swipe left/right as back/forward by default. '2009-05-11 15:24:24' 'Justin Dolske' (In reply to comment #12) > This bug is just rotate, but do we want to consider pinching too? Maybe; it certainly has been noted that people are accidentally hitting that gesture too. Though I think it's a separate decision: rotate is an unnatural gesture for switching tabs (nothing else uses it this way), with a high penalty for accidentally triggering. Pinching is a natural gesture for page zoom (and more widely used/known), with a low penalty for accidentally triggering. I think most people would consider it a bug if we claimed to support multitouch, but pinch didn't do anything. So, I'd strongly lean towards only removing the rotate. Pinchy would've wanted it this way. '2009-05-11 15:32:51' 'Jim Mathies' (In reply to comment #12) > This bug is just rotate, but do we want to consider pinching too? > > If we take those out, we'll have swipe up/down as jump to top/bottom and swipe left/right as back/forward by default. pinch should definitely be left on for win7. Tracking is turned off so you get a nice zoom in/zoom out effect. It's also nearly impossible to trigger without a definitive pinch with two fingers on the screen. '2009-05-11 20:48:28' 'Mike Beltzner' If you want to consider disabling pinch, please file a separate bug, do not conflate. FWIW, I'm not nearly as keen on disabling that one, and am fairly-to-surely likely to WONTFIX such a bug. But go ahead ... try me ;) '2009-05-11 21:29:39' 'Edward Lee Mardak' Created an attachment (id=376850) [details] v1 Don't do anything on os x when twisting. Alternatively, have people tried upping the threshold for twist? It would make it less likely to accidentally trigger. But I just noticed something interesting in os x's gesture detection. - If I use 2 hands (1 finger each) and place one at the top and one at the bottom, moving the top finger registers as a normal mouse move while moving the bottom finger is registered as a twist. I suppose the heuristic there is to assume the top finger is used for scrolling. - Also, if your fingers are too close to the edge, it won't treat it as a rotate. But you can still move the pointer from the edge. '2009-05-19 13:37:50' 'Mike Beltzner' Can we get the patch reviewed - I think we want to remove the rotate gesture on both Windows and OSX. '2009-05-19 13:47:53' 'Edward Lee Mardak' Created an attachment (id=378424) [details] v2 both Windows and OSX. '2009-05-19 23:14:15' 'Mike Beltzner' (From update of attachment 378424 [details]) uir+r=beltzner '2009-05-19 23:57:31' 'Edward Lee Mardak' http://hg.mozilla.org/mozilla-central/rev/d19424342b43 Give empty commands for twist gestures, so they do nothing, but still show up as prefs in about:config. '2009-05-20 16:44:33' 'Edward Lee Mardak' http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3329a3997d7b '2009-05-26 07:58:47' 'Henrik Skupin' Verified fixed on trunk and 1.9.1 with builds on OS X and Windows like: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090525 Minefield/3.6a1pre ID:20090525031110 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre ID:20090526031155 '2009-07-05 13:49:55' 'Nick Lowe' Off the back of this, would there be any chance of getting... browser.gesture.swipe.left.shift added and set to Browser:PrevTab and browser.gesture.swipe.right.shift added and set to Browser:NextTab Having made this change, I must admit to now finding Firefox almost 'alien' to use on other multi-touch machines! '2009-07-05 16:12:40' 'Nick Lowe' https://bugzilla.mozilla.org/show_bug.cgi?id=502500 '2008-10-08 12:51:00' 'Kai Klesatschke' Problem: The method FolderDescription#createExistentResourceFromHandle(IResource,IProgressMonitor) checks if the folder already exists and returns immediately if so. In cases where the FolderDescription has members which are not existing at that moment, that members will not be created. Use case: Assume you want to create a folder and a file in that folder and use two operations for this. I know it is not necessary to use two operations but my configuration is more complex than this example code. IFolder folder = ... // must not exist CreateFolderOperation op1 = new CreateFolderOperation(folder,...); IFile file = folder.getFile(...); // must not exist CreateFileOperation op1 = new CreateFileOperation(file,...); op1.execute(...); op2.execute(...); The execution of the op2 does not create the file because as stated above createExistentResourceFromHandle returns immediately because the parent folder of the file was created by op1. IMHO createExistentResourceFromHandle must check if members of a FolderDescription should be created. '2008-10-08 12:57:20' 'Kai Klesatschke' I checked the code in the ganymede release and the problem should exist there too. '2008-10-22 13:01:23' 'Susan F. McCourt' Is there any reason you cannot execute op1 before creating op2? The basic problem is that the workspace file structure has changed since you first created the operation, so the change described by the operation is no longer valid. '2008-10-23 03:05:42' 'Kai Klesatschke' >Is there any reason you cannot execute op1 before creating op2? No there is not. In the meantime I found a workaround in my code but I think it's very inconvenient that someone must know that op2 have to be created after the execution of op1. The API gave me no hint that I have to do so! Maybe the build of the FolderDescription could be delayed until the execution of op2. Think about cases where the to ops have nothing in common e.g. created and executed in different plug-ins. '2008-10-23 11:12:00' 'Susan F. McCourt' I'll mark this one for M4. I think what needs to happen is that the javadoc better describes the lifecycle of these operations, and the isValid() method is tightened up so that the operation becomes invalid when the workspace changes to no longer match its recorded state. It is not the intention of these classes to stay in synch with workspace changes that happen independently of a shared, sequential workspace history. '2009-01-30 03:35:08' 'Dani Megert' Moving target as M6 has shipped. '2009-04-16 15:30:37' 'Susan F. McCourt' Fixed in HEAD >20090416. In order to understand better what the ramifications might be of actually fixing this bug vs. better documenting the limitations and usage, I started by implementing a trial fix for the problem as reported. It is pretty straightforward to rearrange the code to create the child resources (the file) even if the parent exists since the operation was created. However, the problems occur later when you try to undo such an operation. Since the operation \"remembered\" that the folder didn't exist when it was first created, the undo of the create file operation tries to also delete the folder. This means that to truly fix the bug, we'd have to change the operations so that the resource descriptions were constantly updated to deal with changes that occurred. So I still believe it's better to document more clearly what the intentions of the API are. I've updated the javadoc for AbstractResourcesOperation, CreateFileOperation, and CreateFolderOperation. In addition, I created a stricter validity check on CreateFileOperation so that the operation will return an invalid status if portions of the resource tree already exist. Created WorkspaceOperationsTest.test250125() to simulate this condition. The CreateFileOperation is valid until the CreateFolderOperation is run, at which time the file operation knows it is invalid. '2009-04-16 15:34:13' 'Susan F. McCourt' > In addition, I created a stricter validity check on CreateFileOperation so that the operation will return an invalid status if portions of the resource tree already exist. What I meant to say is... I created a stricter validity check on CreateFileOperation so that the operation will return an invalid status if portions of the resource tree *that did not exist when the operation was created* already exist at the time of execution. It is expected/allowed that the containment tree already exists when the op is executed, as long they also existed when the op was created. '2009-04-28 16:31:24' 'Susan F. McCourt' verified via automated test cases that run on each build. Also verified through source inspection '2008-03-28 09:19:00' 'Tomasz Zarna' Inspired by Martin Oberhuber's mail about his \"lsc\" script for counting lines in a patch[1], I though that it maybe be worthwhile to embed such thing in the Apply Patch wizard itself. imo using regexp should be enough here, especially due to the fact that we don't want to make any additional dependencies. So, my proposal is to allow to specify a regexp rule for lines that should be count as a \"real contribution\". This is what first came to my head: /-\\\\+? (\\s*\\S+\\s*)+$ which means \"Count only lines starting with single '+' and a space. The line must also have at least one non-whitespace character\". I think this is more/less what Martin's script does. All lines that match the above pattern would be sum up and the info would be displayed somewhere on the Apply Patch wizard. How does it sound? Martin? Again, I think it's a brilliant idea Martin. [1] sent to eclipse.org-committers '2008-03-28 09:22:45' 'Tomasz Zarna' The info could be also shown in a patch outline view (see bug 190418). '2008-03-28 09:42:46' 'Martin Oberhuber' Excellent idea! Having the line counter right in the apply patch wizard would finally give us a standard way of counting lines that everybody could use easily. My script also ignores \"empty comment\" lines of the form /-\\\\+\\s+[#*]+\\s+$ but that's really neglectible and I'm fine with your approach of counting any non-empty added line in the patch. Actually, couldn't your regex even be simpler, say /-\\\\+\\s+\\S since you don't need to check till the end of the line? '2008-03-28 09:46:03' 'Martin Oberhuber' And actually, if the wizard counts added lines, why shouldn't it also count removed lines? Giving two separate numbers e.g. 10 lines added 20 lines removed This sounds familiar to me since I've seen similar numbers in RCS files before. I'd guess that the regex for removed lines could just be the same as for added lines but the + replaced by a -; and, files removed entirely should contribute the entire number of lines they had before (I believe that the old contents is not recorded in the diff, is it?) '2008-04-01 09:32:36' 'Tomasz Zarna' Created an attachment (id=94358) [details] Patch Fix that matches all lines from a patch against given regexps (one for added lines and one for removed). Patterns can be changed on General > Compare/Patch pref page. I decided to leave them blank by default, so I don't need to worry about different diff output formats which are out there. However, you can easily set it to a value most convenient to you (i.e. '/-\\\\+\\s+\\S'). '2008-04-01 09:32:39' 'Tomasz Zarna' Created an attachment (id=94360) [details] mylyn/context/zip '2008-04-01 09:38:19' 'Martin Oberhuber' (In reply to comment #4) > I decided to leave them blank by default, so I don't need to worry So this means it won't work out of the box? But then, the compare/patch feature already needs to analyze patches or it cannot apply them, right? So I don't quite understand why the same patterns that compare/patch already uses aren't the default for the line counting feature. '2008-04-02 11:54:35' 'Tomasz Zarna' (In reply to comment #6) > So this means it won't work out of the box? > But then, the compare/patch feature already needs to analyze patches or it cannot apply them, right? > So I don't > quite understand why the same patterns that compare/patch already uses aren't the default for the line counting feature. I guess you're right Martin, but this will make the patch a little bit more complicated as the current patching mechanism is not very helpful in counting added/removed lines. I'll just need some extra time to do this. '2008-04-21 09:11:06' 'Tomasz Zarna' Created an attachment (id=96838) [details] Patch 2 '2008-04-21 09:11:09' 'Tomasz Zarna' Created an attachment (id=96839) [details] mylyn/context/zip '2008-04-21 09:29:15' 'Tomasz Zarna' The latest patch ensures, that when no regular expressions is provided, the patcher will use internal patterns to distinguish which lines have been added or deleted. However, this will work only for patches in unified and context diff output format. As reported in bug 227742, it appears that standard patch format is no longer supported (or it has never been). Moreover, I logged bug 228000 to make sure we add some automated tests to cover this newly added feature. '2008-04-22 05:47:53' 'Tomasz Zarna' Created an attachment (id=96993) [details] Patch 3 Previous patch with some minor adjustments. '2008-04-22 06:29:21' 'Tomasz Zarna' The latest patch applied to CVS HEAD. Martin, would you like to try it out and let me know what do you think? Feel free to open a new bug if there is something I missed. '2008-04-23 21:00:43' 'Martin Oberhuber' I tested this with I20080422-0800, on the attached patch from bug 227572 attachment 97084 [details]. Your dialog counts 207 added and 29 removed lines, but my script only counts 151 added lines. It looks like you are also counting empty lines, which doesn't seem overly useful to me. '2008-04-24 04:44:46' 'Tomasz Zarna' Created an attachment (id=97398) [details] The preference page The \"internal\" mechanism of counting added/removed lines is very simple, it sums up all lines with '+' and '-'. If you want to use your own patterns/script please take a look at the General > Compare/Patch pref page. I've added there two fields where you can customize the way this simple mechanism works. '2008-04-24 07:09:41' 'Martin Oberhuber' It's awsome that this is customizeable, but when I remember right, one reason for putting this enhancement into Eclipse SDK was such that there is a \"common standard\" by which the projects count their lines in a patch. I think that this \"common standard\" should be as good as possible by default. On the other hand, having some magic like removing empty lines from the count going on in the background is perhaps a problem... would it be possible to keep your current count (\"211 added / 53 removed lines\") but add an additional count without empty lines e.g. Note that I'm only talking about empty lines here, e.g. Regex \"/-\\\\\\s*$\". I agree that we cannot count empty comments here by default, because comment styles differ by language. Actually, it might be a good idea to have one additional kind of Regex pattern in the Preferences, which acts as a filter -- suggested tooltip behind //: Added Lines: /-\\+ Removed Lines: /-\\- Filter: /-\\[+-]\\s*$ //Filter for lines to not count, e.g. empty lines providing an output such as \"Patch contains 207 added and 29 removed lines (151 / 27 filtered)\" '2008-04-24 08:46:47' 'Tomasz Zarna' Martin, I see your point when you're saying that the \"common standard\" should be as good as possible, however I would rather not to filter any lines from a patch when parsing. Here are the approaches so far: 1) Use only given filters, by default no counting will be made. This is how the patch from comment 4 worked. Rejected. 2) By default count lines using the simple patterns, which are currently used when parsing a patch (ie \"+\" and \"-\"), this can be modified in the pref page. Patch in comment 13. In HEAD. 3) By default count lines using more sophisticated patterns like excluding empty lines. And again, this can be modified in the pref page. If I understood you correctly this is what you meant in comment 15. My main concern here is: what if I would like to know total number of lines added in the patch (the filter idea looks to be an answer here but it's a pref value, it's not embedded in the parser itself, right?) 4) By default count lines using both simple and sophisticated patterns at the same time. The output would be something like this \"Patch contains X added and Y removed lines + Z added lines which are empty\". Again, the user could provide his own patterns... which makes the whole mechanism overblown and not as intuitive as I would like it to be. Regarding the filter idea: it sounds good to me, but I think we should move the discussion about it to a separate bug. Would you mind opening one? btw, thanks for your feedback Martin. '2008-04-30 08:53:01' 'Tomasz Zarna' Verified in I20080429-0100. Martin are you willing to open new bugs to address your concerns? '2008-05-02 19:08:09' 'Martin Oberhuber' FYI, following regex suppresses lines in the patch from counting, which are empty or only contain non-wordchars (i.e. lines which only contain an } or only contain a * as continuation of an empty Javadoc comment: Added: /-\\\\+[/-\\+]+[a-zA-Z0-9_!?\"|@~`$%&()+;,.:<>=+-] Removed: /-\\-[/-\\-]+[a-zA-Z0-9_!?\"|@~`$%&()+;,.:<>=+-] '2008-03-24 17:36:00' 'Angel Vera' According to the javaDoc in Platform.getResourceString(Bundle,String), this method has been deprecated and one should use the NLS class or the BundleFinder.find(). I was able to find the NLS class but I didn't find the BundleFinder class. Is the javaDoc correct? if it is a hint on where to find the BundleFinder class would help. The NLS class doesn't seem to provide me with the same functionality that Platform.getResourceString does, so I am assuming that BundleFinder would do the job that I need. Please provide me with more information on where to find the BundleFinder and improve the javaDoc. '2008-03-25 09:57:01' 'Oleg Besedin' I don't think that replacement functionality was ever implemented. Pascal, you added bunch of comments like that to the Platform ver. 1.92. As there are no current plans to act on them (and there has been no actions done in the last 2 years) I think we need to remove those comments - they make a rather confusing Javadoc. There are 21 \"XXX\" comments that should be removed from Javadoc or acted upon. '2008-03-25 09:59:06' 'Oleg Besedin' Adding M7 as a milestone to remind to remove those comments. '2008-03-25 11:55:35' 'Angel Vera' (In reply to comment #1) > I don't think that replacement functionality was ever implemented. > Pascal, you added bunch of comments like that to the Platform ver. 1.92. > As there are no current plans to act on them (and there has been no actions done > in the last 2 years) I think we need to remove those comments - they make a rather confusing Javadoc. > There are 21 \"XXX\" comments that should be removed from Javadoc or acted upon. So are you saying that the support for using getResourceString has just been droppped, and that no replacement will be available? that concerns me because WTP has a code that uses this method, and I am sure that there is plenty of adopters that are currently using that function as well. '2008-03-25 13:27:23' 'Oleg Besedin' The method Platform.getResourceString(Bundle,String) is not deprecated at this time; the comments should have been added to the implementation code or to a bug report, not to the Javadoc of the Platform class. '2008-05-23 04:29:23' 'Philippe Mulet' Please adjust the target milestone, so it does not point at a closed milestone in the past. '2008-09-24 16:17:37' 'Oleg Besedin' From bug 247983 other tagged methods: -getResourceBundle(Bundle) -getResourceString(Bundle, String) -getResourceString(Bundle, String, ResourceBundle) '2008-09-24 16:18:04' 'Oleg Besedin' *** Bug 247983 has been marked as a duplicate of this bug. *** '2008-09-24 16:42:07' 'Oleg Besedin' Removed incorrect comments from the Platform class. '2008-09-24 16:49:49' 'John Arthome' We collided, I just made the same changes. The only difference is that I moved the comments to InternalPlatform. Also I deprecated Platform#endSplash since this has been replaced with IApplicationContext#applicationRunning(). '2008-06-07 10:59:00' 'Tsahi Asher' the about:mozilla page in RC2 is right-aligned, but has LTR directionality instead of RTL. as a result, the dot at the end of the sentence is on the right side instead of the left, and both the parentheses around the \"10th edition\" line are on the right side. i also think the quote source should be on the left side. perhaps the page should take CSS from intl.css, where localisers can override some of the classes or add a class to set direction. '2008-06-07 11:12:04' 'Tomer Cohen' Actually I would like not to add yet another entry in intl.css but to fix it in aboutMozilla.xhtml. Pike, can we think about it? '2008-06-07 11:23:41' 'Tomer Cohen' Same behavior also affect other internal about pages. * about:plugins pages that get RTL: * about:crashes * about:robots - Has some open issues. See bug 427029 Pages that not translated, such as about:cache, about:credits and about:buildconfig should stay LTR. '2008-06-07 12:19:57' 'Tsahi Asher' the about:mozilla page used to be a file in the language pack, allowing the localizer to control it's look. moving this out of the language pack created this problem. '2008-06-07 12:25:41' 'Tomer Cohen' the file dom/chrome/global.dtd control has direction control with the entity locale.dir. We can, actually, support RTL using something like <body dir=&locale.dir;>. '2008-06-07 13:01:50' 'Tomer Cohen' Created an attachment (id=324147) [details] patch Here is my patch. Tested on Hebrew locale. Please let me know if you prefer 'body{direction:&locale.dir;}' instead of the current '<body dir=\"&locale.dir;\">'. '2008-06-07 13:42:01' 'Tsahi Asher' the W3C prefers markup and not CSS: http://www.w3.org/International/questions/qa-bidi-css-markup \"Because directionality is an integral part of the document structure, markup should be used to set the directionality for a document or chunk of information, or to identify places in the text where the Unicode bidirectional algorithm alone is insufficient to achieve desired directionality.\" '2008-06-07 14:07:22' 'Tomer Cohen' (In reply to comment #6) > the W3C prefers markup and not CSS: Actually I'm not sure how we can do it using CSS. I have no idea if something like 'body{direction:&locale.dir;;}' is a valid. '2008-06-08 07:51:42' 'Axel Hecht' To me, the trunk solution for this is to have a separate entity for each of those pages, to work around bugs like bug 427029. Once you localize a page we ship, you would then set the dir from ltr to rtl. That's not a solution for the 1.9 branch, though, there we should just re-use locale.dir from global.dtd. IMHO. Gavin, what do you think? '2008-06-11 11:38:12' 'Gavin Sharp' (In reply to comment #8) > To me, the trunk solution for this is to have a separate entity for each of those pages, to work around bugs like bug 427029. > Once you localize a page we ship, you would then set the dir from ltr to rtl. > That's not a solution for the 1.9 branch, though, there we should just re-use locale.dir from global.dtd. Sounds fine to me, I guess... do we really need to worry about the \"RTL locale that's falling back to en-US\" though? Ideally we could just take this patch and not worry about having localizers update various different attributes based on localization state, and just rely on them completing all the localization work to make it look decent. '2008-06-11 11:40:38' 'Gavin Sharp' In other words, isn't bug 427029 an edge case given the nature of about:robots and it's \"optional\" status for localizers? Seems like we could just live with it not looking perfect for RTL locales that haven't localized it rather than adding complexity. '2008-06-11 11:43:45' 'Axel Hecht' Well, that depends on how disciplined folks are. We could make that call per page, like in the case of the robots page, it might make sense to have an open window for not translating it, for neterror pages probably less. There we could even get extreme and do it per div ;-). '2008-06-11 12:55:16' 'Tomer Cohen' I'm adding another screenshot to bug 427029. Axel, Gavin - You are welcome to comment on that issue right there. '2008-06-29 10:48:37' 'Tomer Cohen' We are not far from 1.9.0.1 deadline. Please approve1.9.0.1. Thank you. '2008-07-17 16:05:29' 'Samuel Sidler' Please get this landed on mozilla-central before getting approval for 1.9.0.x. '2008-07-20 23:25:20' 'Samuel Sidler' (From update of attachment 324147 [details]) Please re-request approval after getting this landed on mozilla-central. I'm not really sold on taking this given that it's more \"cosmetic\" than anything else... '2008-08-03 09:30:00' 'Dao Gottwald' http://hg.mozilla.org/index.cgi/mozilla-central/rev/d12488eef3f5 '2009-01-09 00:28:00' 'Brian Vosburgh' Here is the JavaDoc for IAdapterManager.computeClassOrder(Class): Returns the class search order for a given class. The search order from a class with the definition class X extends Y implements A, B is as follows: - the target's class: X - X's superclasses in order to Object - a breadth-first traversal of the target class's interfaces in the order returned by getInterfaces (in the example, A and its superinterfaces then B and its superinterfaces) This comment is not perfectly clear. In particular, it does not complete the example by explicitly listing the exact order the example classes and interfaces are returned. I came up with a slightly richer example: interface A extends M, N interface B extends O class Y implements C, D class X extends Y implements A, B [The declarations for interfaces C, D, M, N, and O are trivial.] The order of classes and interfaces returned by AdapterManager.computeClassOrder(X) is: class X interface A interface B interface M interface N interface O class Y interface C interface D class java.lang.Object This conflicts with the JavaDoc. The class X is the first thing returned, but it is *not* followed by \"X's superclasses in order to Object\". It is followed by a breadth-first list of X's interface hierarchy\", *then* followed by X's superclass Y, which is then followed by a breadth-first list of Y's interface hierarchy; and so on, up to java.lang.Object. Also, the JavaDoc has what reads to me as a contradiction: a breadth-first traversal of the target class's interfaces in the order returned by getInterfaces vs. in the example, A and its superinterfaces then B and its superinterfaces What actually happens *does* feel like a \"breadth-first\" search; but that would not be accurately described as \"A and its superinterfaces then B and its superinterfaces\". But maybe I'm reading it wrong.... It might be worth discussing which is the \"preferred\" behavior: the behavior described by the JavaDoc or the behavior implemented in AdapterManager. In some ways having all the classes first, followed by the interfaces might make more sense than the current implementation.... But, then you have the whole \"backward-compatibility\" thing to worry about.... '2009-01-09 10:58:43' 'John Arthome' You are right on both counts. The implementation doesn't match the spec, and there is a contradiction in the spec itself. Now the question is what do we do about it. - For the contradiction, I think we should stick with the breadth-first search, and delete the parenthetic comment about the example (\"A and its superinterfaces then B and its superinterfaces\") - For the spec not matching the behaviour, my instinct is to \"fix\" the spec to match the implementation, to avoid the risk of breaking clients. This would be a very subtle change that could affect clients in unpredictable ways. On the other hand if there are really compelling reasons to change the implementation to match the spec, I'd be curious to hear them. I did some research and found that the implementation did match the spec until Febuary 20, 2004, when I change the implementation. At that time the spec wasn't part of the API. The spec was later added to the API (IAdapterManager#computeClassOrder) without checking that the implementation still matched. I'm going to do some more archeology to see if I can figure out why I changed the lookup order. '2009-01-09 11:51:01' 'Brian Vosburgh' It would be interesting to know what triggered the change in behavior. I guess the question is whether superclasses take precedence over interfaces defined lower in the hierarchy, i.e. does the implementation take precedence over the specification? I can see arguments for either way; but I guess I would probably come down on the side of giving specification precedence. So, I guess you argue further that all the interfaces could precede all the classes? Argh...why did I even ask? :-) Anyway, I don't have any use cases at the moment to argue one way or the other. It's just that my curiosity got the better of me, after years of wondering, \"Just how does the Platform resolve which adapter to return?\" :-) '2009-01-12 12:02:41' 'John Arthome' It looks like this change was made inadvertently during a large batch of changes to add support for the adapters extension point (bug 32498). I think since this change was introduced accidentally, and this is a clear violation of a long-standing specification, I'm leaning towards fixing the implementation. I noticed the spec also doesn't mention the interfaces of the target class' superclasses. I think the corrected spec should read: * <ul> * <li>the target's class: X * <li>X's superclasses in order to <code>Object</code> * <li>a breadth-first traversal of the target class's interfaces in the order returned by <code>getInterfaces</code> (in the example, X and its superinterfaces then Y and its superinterfaces) </li> * </ul> Note that the comment changed to \"X and its superinterfaces then Y...\" as opposed to \"A and its superinterfaces then B...\". Thus this clarifies how the interfaces of superclasses are considered, while fixing the contradiction in the specification of interface search order. '2009-01-12 12:03:42' 'John Arthome' Created an attachment (id=122293) [details] Fix v01 '2009-01-12 12:11:27' 'John Arthome' Created an attachment (id=122297) [details] Test case This is a test case using your richer example '2009-01-13 10:47:18' 'John Arthome' Fix and tests released to HEAD. '2009-01-13 11:57:25' 'Brian Vosburgh' Sounds reasonable. One tiny nit-pick though. The last entry in the bullet list now reads: a breadth-first traversal of each class's interfaces in the order returned by <code>getInterfaces</code> (in the example, X and its superinterfaces then Y and its superinterfaces) </li> It might be more accurate to say: a breadth-first traversal of each class's interfaces in the order returned by <code>getInterfaces</code> (in the example, X's superinterfaces then Y's superinterfaces) Since X and Y are not actually included in the \"traversal\". Thanks. '2009-01-13 13:05:18' 'John Arthome' Good point, I have released this clarification to HEAD. Thanks again. '2006-02-25 16:04:34' 'Nathan M' User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)Gecko/20050915 Firefox/1.0.7 (ax) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)Gecko/20050915 Firefox/1.0.7 (ax) Firefox currently supports a wide number of stand alone e-mail applications (including it's own Thunderbird client), when an e-mail link is clicked on in Firefox. To the best of my knowledge it still does not support web based e-mail clients such as g-mail in this fashion. The idea is that if one prefers to use a web based e-mail account, they should have the option to configure firefox to log into that web based e-mail account and open a compose new message window. I understand this may require some colaboration with the popular web based e-mail services such as gmail and aim mail, but I think it would be worth the benifit. Reproducible: Always '2006-02-26 01:01:53' 'Ria Klaassen' Something like the WebmailCompose extension? '2006-02-26 01:03:00' 'Jesse Ruderman' Other enhancement requests like this have been marked as dups of bug 11459, but I think that's wrong. As far as I can tell, bug 11459 is a combination of a design flaw specific to Seamonkey and a tangentially related enhancement request that also applies to Firefox, and nothing is happening there. It's sad that mailto: links don't work for most webmail users, especially since webmail is so popular. Webmail services can help give users programs that alter system mailto: behavior (e.g. the unofficial \"G-Mailto\" and the official \"Gmail Notifier\"), and Firefox users can download the WebmailCompose extension, but i think it would be better if this were an option in Firefox itself. '2006-03-13 08:41:47' 'Mike Connor' Not going to block on this, would be good to have this generically for feeds as well, but this may have to wait for Gecko 1.9 '2009-06-19 09:53:34' 'Ian Pottinger' Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090615 Firefox/3.5 Is this not now fixed? '2009-06-19 09:55:20' 'Dan Mosedale' Indeed. '2004-10-30 14:39:50' 'David Odin' Open a new image, create a layer much bigger than the image, and with a different aspect ratio. draw something on the drawable (using some colors) make a selection selecting only some parts of your drawing use the channel mixer. The selection looks wrong in the plugin, and the plugin can even crash. This is due to the fact that the selection mask is taken with gimp_drawable_get_thumbnail_data () in the preview code. So if the layer and the image have different size, they are streched differently. '2004-12-27 18:25:34' 'weskaggs' Clearly what it is doing is bad, but what *should* it be doing? Should the preview follow the shape of the selection bounds, the image, or the drawable? '2005-03-24 20:35:14' 'popolon' On a big image, use crop tool on right, bottom or right bottom, click on resize. The active picture is then little than the layer. Using any tool with preview give a one pixel (or less ;) ) preview instead of the good one. Compute intersection between layer and active picture could be the solution... '2005-03-24 23:56:45' 'weskaggs' As far as I can see, there are two reasonable options, and either of them will require a substantial amount of fixing in the aspect preview code and the plugins that use it. (1) Show the entire drawable in an aspect preview, and mask changes using the current selection. (2) Show only the part of the drawable lying within the selection bounds. It isn't clear to me which of them is better. '2006-05-19 21:53:39' 'weskaggs' Bumping to 2.4 since this is not likely to get fixed for 2.2 '2006-05-20 23:16:36' 'weskaggs' Bumping to Future since this is not likely to get fixed for 2.4. '2006-08-14 13:25:51' 'Sven Neumann' Setting back to the 2.4 milestone since it's a crash and should, if possible, be looked at before the 2.4 release. '2006-12-18 20:59:40' 'Sven Neumann' Fixing this might make API changes necessary. We need to look into this as soon as possible. '2007-05-05 20:43:44' 'Sven Neumann' It would help a lot if someone could attach an example XCF file to this bug report that shows the problem. '2007-06-04 19:38:33' 'Eric Lamarque' Created an attachment (id=89354) [details] bug156905.xcf.bz2 - a layer bigger than image Following assertion failed using Channel mixer on the layer. (channel_mixer:6701): LibGimpWidgets-CRITICAL **: gimp_preview_area_mask: assertion `mask != NULL' failed '2007-08-21 11:18:45' 'Aurimas Juska' Doesn't channel mixer use GimpZoomPreview (not GimpAspectPreview)? Seems like both GimpZoomPreview and GimpAspectPreview have problems when steps in reporter's comment are taken. '2007-10-14 21:55:37' 'Simon Budig' This one is nasty to track down. The example image has dimensions 377*233, the selection starts at x=125, y=97 and extends to the lower right corner of the image. The preview code then calls gimp_drawable_get_sub_thumbnail on the selection mask with the following coordinates: src_x: 117, src_y: 89, src_w: 268, src_h: 152 which unsurprisingly fails, since src_x+src_w is bigger than the selection mask width. The source coordinates seem wrong to me and originate from gimp_zoom_preview_get_source_area(), but I have not yet tracked this down. '2008-08-31 16:04:51' 'Aurimas Juska' Created an attachment (id=117704) [details] GimpZoomPreview handle layer offsets This patch should fix GimpZoomPreview to handle layers with offsets with selections. Area displayed in preview is intersection of layer and selection. If there are no objections, I could commit the patch. '2008-08-31 17:35:17' 'Aurimas Juska' For GimpAspectPreview selection mask has to be applied for thumbnail of the whole drawable (selection can intersect partialy with drawable area). '2008-09-01 20:06:56' 'Sven Neumann' Please commit this. It doesn't make sense to patch 2 [details].4 at this point. So please do this in trunk only. '2008-09-02 17:58:01' 'Aurimas Juska' 2008-09-02 Aurimas Juška <aurisj@svn.gnome.org> >-------* libgimp/gimpzoompreview.c (gimp_zoom_preview_draw_buffer), >-------(gimp_zoom_preview_set_drawable): fixed GimpZoomPreview to handle >-------layers with offsets and display intersection of layer and selection >-------in the preview. (bug #156905) '2005-01-23 16:11:42' 'Jaap A. Haitsma' When images are rescaled now the GIMP always defaults to linear scaling. Sometimes I want to do a bunch of images with cubic scaling. It would be handy that the scale dialog just remembered the last setting and always present that one. '2005-01-23 16:43:42' 'Sven Neumann' The default interpolation routine can be choosen in the Preferences dialog. '2005-01-23 16:54:22' 'Jaap A. Haitsma' I just thought it would be easier if it just remembered the last setting, that way a newbie does not have to search trough the preferences, and it is handy if you want to scale a set of images in a different way as normally '2005-01-23 20:18:39' 'Albert Cahalan' Jaap is right. I didn't know about the preferences setting until I saw this bug report. This applies in general to options that the user can set without going into the preferences dialog: just remember the last setting, and there is no need for an entry in the preferences dialog. '2005-01-23 20:32:27' 'Michael Schumacher ' We would need an entry whether to save the last used setting, for the users who don't want this. '2005-01-23 22:13:02' 'Jaap A. Haitsma' Michael, I don't agree with having an extra entry whether to save the setting yes or no. This would clutter the interface even more. Because you then still need an entry in preferences and you need an extra entry in the scale dialog whether to save the last used setting. Just always remembering the last setting is conceptually by far the easiest for new users. Furthermore I think it's not really a problem if you have to change the setting now and then (In your case you also have to click once more to not save the setting). And most of the times you will not change this setting. '2005-01-24 10:27:50' 'Raphaël Quinet' I agree that it is convenient to be able to set a default value from the place it is used (e.g., the Image->Scale dialog) instead of having to open the Preferences and find the corresponding option. This is very useful for those who are not familiar with all options available in the Preferences. However, I disagree with the proposal that the last setting should automatically become the default: I have set the default to Cubic (I might change it to Lanczos soon) and I expect it to be used all the time. But from time to time, I scale up a bitmap image without interpolation. I don't want this to become the new default and give me bad results when I scale up another image two days later. So if there is a way to change the default from the Scale dialog (which is probably a good idea), then it should require an explicit action from the user. This could be a button like \"set default\" or a checkbox \"remember this setting\" next to the \"Interpolation type\" dropdown list. '2006-09-24 09:14:11' 'gg' >>Jaap is right. I didn't know about the preferences setting until I saw this bug report. LOL, me too. I think the suggestion for a \"set as defaults\" button here is a good all-round solution that satisfies both camps. See this bug for request to deal with scaling units (percent/pixel) in the same way. http://bugzilla.gnome.org/show_bug.cgi?id=357424 '2006-10-14 16:56:40' 'Michael Natterer' I think a \"set as defaults\" button would clutter the UI. This change remember the settings across dialog invocations. Closing as FIXED. (Please reopen if you strongly disagree, but please not without a non-ugly suggestion for a GUI) 2006-10-14 Michael Natterer <mitch@gimp.org> Remember the settings in the scale and resize dialogs for images and layers. Fixes bug #164995, bug #316392, and bug #357424. * app/dialogs/scale-dialog.h: removed GimpScaleCallback typedef. * app/dialogs/dialogs-types.h: added it here. * app/dialogs/image-scale-dialog.[ch]: made the ImageScaleDialog struct private, return a GtkWidget* from image_scale_dialog_new() and use a GimpScaleCallback in the public API. * app/actions/actions-types.h: #include \"dialogs/dialogs-types.h\" * app/actions/image-commands.c: changed according to image scale dialog changes. Remember the scale dialog's unit (if it is \"percent\") and interpolation type across dialog invocations. Also remember the resize dialog's unit (if it is \"percent\"). * app/actions/layers-commands.c: remember scale and resize dialog stuff as in image-commands.c '2005-03-18 14:46:31' 'Xuan Baldauf' 1. Open a large grayscale image of your choice (e.g. larger than 2000*2000 pixels, maybe a scan result from your scanner) 2. Use \"Tools/Color Tools/Threshold\" to apply some threshold choosen arbitrarily. This tool is pretty fast. 3. Now you have a 8bit grayscale image, which actually consists only of color values \"0\" and color values \"255\". Converting it to a 1bit black&white image should be a very fast operation (replacing 0 (8bit) by 0 (1bit) and replacing 255 (8bit) by 1 (1bit)), but it is not: 4. Choose \"Image/Mode/Indexed...\", and there: 4.1 Colormap: \"Use black and white (1-bit) palette)\" (this should be the fastest option possible) 4.2 Dithering: \"none\" (this should be the fastest option possible) 4.3 Now hit \"OK\" 5. The conversion will work, but it will take many seconds. For an example image of \"2460*3483\", it takes 34 seconds on my computer (while applying the Threshold tool, which basically does the same, only needs maybe 2 seconds). This slow speed is not acceptable for interactive image processing, and this slowness is not necessary at all. '2005-03-18 17:07:32' 'weskaggs' Indeed it is very slow, so I will confirm this bug report. There is, however, a workaround. I found with a little experimentation that if you use the \"Optimal Palette\" option for step 4.1, then the conversion occurs in a flash, literally a fraction of a second for me. This happens, I think, because if you use this option, by the time the algorithm reaches the stage of actually converting the image, it has built a color histogram and \"knows\" that there are exactly two colors in the image, and can assign colors directly, without having to test whether black or white is the best match for each pixel. Because of the existence of this workaround, I am going to lower the severity, but this *is* something that should be looked into. '2005-03-18 17:36:31' 'Xuan Baldauf' Created an attachment (id=38911) [details] Image where to 1bit conversion is either slow or buggy (with GIMP 2.2.4) That's odd. I just tried to use your suggested workaround and was happy that the conversion was as fast one should expect. However, the conversion was plainly wrong, it produced an image which was just black (the input image was nearly white). I'm attaching a test case image. This may be a related bug. Do following on the atached image: 1. Choose \"Image/Mode/Indexed...\", and there: 1.1 Colormap: optimal palette (wether 2 oder 256 colors, it does not matter) 1.2 Dithering: \"none\" (but I think it does not matter) '2005-03-18 18:02:11' 'weskaggs' Interesting -- clearly the generation of an optimal palette is not done correctly for this image. Because this is a different issue, I am going to open a different bug report for it -- using your image as example, if you don't mind. In any case, I've found a solution to the original problem, I think. I found a very simple change that gives a major speedup when converting grayscale images to the mono palette. It's now at least as fast as the Threshold tool, so I'm going to resolve this bug as FIXED. Still just as slow for RGB images, though. Committed to both branches: 2005-03-18 Bill Skaggs <weskaggs@primate.ucdavis.edu> * app/core/gimpimage-convert.c: when converting grayscale to mono, treat the palette as gray rather than rgb, giving more than tenfold speedup. Fixes bug #170801. The new problem is described in bug #170825 '2005-03-18 18:08:42' 'Xuan Baldauf' I'd be pleased if you used my test case image. :-) Thank you for fixing this bug so fast, so I just need to wait for the next release. (Building for Windows would be rather messy, so I try to be patient...) '2005-03-19 13:12:31' 'Adam D. Moss' I'm interested in seeing the patch. If you can't attach it then what revision of gimpimage-convert.c contains the fix? '2005-03-19 17:48:16' 'Manish Singh' Revision 1.156. Here is the patch: --- gimpimage-convert.c 27 Feb 2005 14:03:50 -0000 1.155 +++ gimpimage-convert.c 18 Mar 2005 17:34:34 -0000 1.156 @@ -4057,7 +4057,6 @@ initialize_median_cut (GimpImageBaseType } if (palette_type == GIMP_WEB_PALETTE || - palette_type == GIMP_MONO_PALETTE || palette_type == GIMP_CUSTOM_PALETTE) { switch (dither_type) '2005-03-19 18:14:01' 'Adam D. Moss' Thanks. That's interesting. I expect it to yield poorer results though, to some extent (probably most obviously darker, or lighter, in mid-greys, that is a damaged gamma), because the greyscale colour-matching and error-quantifying is in a comparatively non-perceptually-uniform space (that's half the reason why it's faster, though it's not as big a quality difference in a greyscale source as an RGB source). Were side-by-side comparisons done? I hope so, though I could do some here if anyone cares. '2005-03-19 18:21:59' 'Manish Singh' I don't think anyone has done side-by-side comparisons. '2005-03-20 12:18:10' 'Adam D. Moss' differences, but not so strong that I'm really going to lose any sleep. '2005-03-20 12:26:09' 'Adam D. Moss' Note that the analysis in comment #1 is correct; the 'optimal' palette finder does a first pass to see if there are already a suitable number of colours, and then knows that it can skip both the expensive quantization and dithering stages. The 'mono' palette option doesn't even bother to start this pre-pass because it could only possibly pay off the extra effort if the entire image is pure black and pure white, which is expected to be a comparatively rare occurance. '2005-03-20 13:06:07' 'Xuan Baldauf' > The 'mono' palette option doesn't even bother to start this pre-pass because it could only possibly pay off the extra effort if the entire image is pure black and pure white, which is expected to be a comparatively rare occurance. I don't think that this operation is so rare, because for getting an \"optimal distribution between black and white\" for grayscale images (for example: you want to generate faximilies the receiver actually is able to read), you use the \"threshold\" operation, and then a \"convert to 1bit\" operation to actually adjust the internal memory requirements. So at least for me, this chain of operations is rather frequent. '2005-03-20 14:01:48' 'Adam D. Moss' > and then a \"convert to 1bit\" operation to actually adjust the internal memory requirements. If you mean GIMP's internal memory requirements you're wasting your time -- all Indexed images are 8/16bpp internally (the same as greyscale images), so you're not saving any memory (instead you may be using quite a lot more, for various reasons). '2005-03-20 14:04:13' 'Xuan Baldauf' I mean OpenOffice's internal memory requirements. For having 10 or 20 fax pages in one OOo document, it quite makes a difference wether they are 8bit or 1bit. '2006-10-24 23:31:40' 'apf' Please describe the problem: When going to File->Acquire->Screenshot in the Windows port of the development build GIMP 2.3.11, firstly there are two different entries \"Screen Shot\" and \"Screenshot\" and secondly, functionality to grab only a portion of the screen is broken. There is no option to \"Select a Region to Grab\" when the user chooses \"Screen Shot.\" However, this option exists in the dialogue box that appears after the user selects :Screenshot.\" However, the functionality does not work, even after selecting a long delay period. Instead, the whole screen is captured each time. I was expecting the mouse cursor onscreen to change to \"crosshairs\" or something similar to allow me to select the region I required. Steps to reproduce: 1. Launch GIMP 2.3.11 Development for Windows on a Windows 2000 platform. 2. Got o File->Acquire->Screenshot. (Note the two different entries for \"Screen Shot\" and \"Screenshot\".) 3. Tick \"Select a Region to Grab.\" 4. Set the delay. 5. Click \"Grab.\" Actual results: The whole screen is captured each time. Expected results: The ability to select a portion of the screen would be available, probably via mouse click-and-drag functionality. Does this happen every time? Yes. Other information: '2006-10-24 23:40:30' 'apf' (I presume the two entries for screenshots under the submenu are there in order to test old and new code, by the way but I just noted it in case there was an issue.) D. Le Sage APF Hobart, Tasmania '2006-10-25 13:13:37' 'Sven Neumann' We know that the port of the screenshot plug-in for Windows is incomplete. What's this bug-report about? Do you want to contribute the missing bits or do you want us to disable the plug-in for the Windows platform? We are waiting for a volunteer to implement the missing functionality for more than a year now. Perhaps it's about time to drop support for the Win32 platform completely. '2006-10-27 01:18:43' 'apf' Sven, The bug report was to alert you in case you did not know it was broken. You are obviously aware it is incomplete. Perhaps you should disable it to prevent more questions from users. I am not a programmer so I cannot implement the functionality. I am trying to do my part by reporting issues for you. You have complained before about how short of volunteers you are. If this is the case, perhaps it is a very good idea to drop support for Win32 and consolidate on making sure the *Nix implementation is as good as possible. Supporting Win32 is probably just draining more resources away. '2006-10-27 10:21:23' 'Michael Schumacher' IIRC Tor is working on this. '2006-10-27 11:49:39' 'Sven Neumann' apf, you are using a development version. Of course there are incomplete and even broken features in there. If you are just a user, you should be using the stable release. Tor said that it is impossible to implement the look and feel of the X11 screenshot plug-in on the Windows platform. He suggested that we stick with Winsnap for the Win32. 2006-10-27 Sven Neumann <sven@gimp.org> * configure.in * plug-ins/common/plugin-defs.pl * plug-ins/common/Makefile.am: reverted changes from 2006-04-06 and build screenshot plug-in optionally again. Fixes bug #364852. * plug-ins/common/mkgen.pl: reverted addition of 'extralibs' parameter that was introduced for the screenshot plug-in only. '2005-02-28 18:44:07' 'Dennis Schaaf' Please describe the problem: When I try to export reports that contain graphs gnuCash just creates an empty html file. Also it is not clear that the export can only do html files. The first time I ran export I triped to save as .jpg and it created a html file named foo.jpg Steps to reproduce: 1. In gnuCash go on reports and create any report that contains a graph 2. In the report window click on Export 3. Save export to \"foo.html\" Actual results: An empty HTML file is saved Expected results: A HTML file with a nice graph Does this happen every time? Yes Other information: '2005-03-01 09:55:26' 'Christian Stimming ' Yes, that's true -- the current graphing code, which uses the graphical library \"Guppi\" which is a dead project, can only produce the on-screen diagrams *and* print these to postscript, but it cannot export these diagrams into pictures that are embedded in a HTML-file. In other words, you can only print the diagrams to postscript but not export them to HTML. This is not going to change before the gnome2 port is completed, because we need to switch to a different graphical library before anything related to this can be changed. See http://gnomesupport.org/wiki/index.php/GnuCashPortingStatus for the porting status. '2006-02-24 01:03:38' 'Josh Sled' Definitely keep it as a reminder. We should be able to coax anything into giving us a PNG; GOG supports SVG export, too. But it looks like gtkhtml doesn't support saving <object /> data. Because it sucks ass. '2007-01-03 11:46:11' 'Fred Blaise' This is still valid for me with version 2.0.4 on opensuse 10.2. This is a real problem not to be able to export these reports. This shouldn't be tagged 'enhancement' anymore, but brought up higher. What's the status on this? Thank you. '2007-01-03 15:24:29' 'Josh Sled' (In reply to comment #4) > This is still valid for me with version 2.0.4 on opensuse 10.2. > This is a real > problem not to be able to export these reports. > This shouldn't be tagged 'enhancement' anymore, but brought up higher. > What's the status on this? There's no change on this. I wonder if the more recent gtkhtml supports getting at <object />s, or if the more recent GOG makes it trivial to create a PNG. In any case, I hesitate to do so, but I've raised the severity to Normal -- a minor part of the component (Reports, export, graphs) does not work. (FWIW, Fred, it's not going to get fixed any faster at Normal than at Enhancement.) '2007-08-08 00:49:35' 'datakid' I can confirm this using GnuCash 2.0.5 on Ubuntu 7.04, feisty fawn...and I can confirm that it's frustrating.... '2009-01-01 15:06:33' 'Beto Zamora' 2.2.8, still doesn't have this needed feature... Frustration also confirmed. '2009-04-26 19:37:33' 'Phil Longstaff' GtkHtml provides a callback when it encounters a <object> tag, and gnc-html then calls gog to create the image as a GdkPixbuf and then embed it in the web page. For the webkit port, there is no <object> callback. Therefore, gnc-html-webkit pre-parses the html string, finds the <object> tag, calls gog with the parameter values from the <object> to create a GdkPixbuf, then converts the pixels to png/base64 and embeds the html <img> in the original where the <object> was. Result is a graph that displays in webkit. In addition, gnc-html-webkit saves the html passed to webkit and handles the export itself by writing that html to a file. This fix is targetted for 2.4. I can also convert gnc-html-gtkhtml to use these two features (convert graph to embedded <img> and do the export rather than getting gtkhtml to do it) for those who can't build 2.4 with webkit. '2009-06-20 22:59:59' 'Phil Longstaff' It turns out that gtkhtml (at least the version I have on Ubuntu 9.04) doesn't support inline images. Therefore, this will only be possible using webkit. '2005-11-15 14:19:15' 'Christian Stimming ' The gnucash-1.8.x series is no longer developed. We may keep this enhancement request as a reminder, though. '2008-03-17 11:45:56' 'Sebastian Bacher' Using the current gvfs svn and nautilus 2.22.0, when doing a dnd from a directory on a proftpd server nautilus returns a file not available error. It does the same when trying to delete the directory. Copying the same directory using mirror in lftp works correctly '2008-04-08 16:15:31' 'WladyX' i get this too. '2008-05-27 16:53:18' 'Martin Jürgens' yup me too '2008-05-27 19:04:15' 'Justin Haygood' *** Bug 524421 has been marked as a duplicate of this bug. *** '2008-05-27 21:52:16' 'Hans Petter Jansson' We're getting this in openSUSE too, and it seems to happen with all kinds of FTP servers. '2008-05-27 21:52:40' 'Hans Petter Jansson' The openSUES bug is https://bugzilla.novell.com/show_bug.cgi?id=382360 '2008-05-28 16:04:30' 'Tomas Bzatek' This is caused by broken backends. Any attempts to open or copy/move a directory should fail with G_IO_ERROR_IS_DIRECTORY. GIO functions and Nautilus rely on that. Fix for gvfs-smb is now in trunk and gnome-2-22 branch. Working on FTP fix right now. '2008-05-30 15:28:33' 'Tomas Bzatek' Created an attachment (id=111807) [details] gvfs-ftp-read-directory.patch Proposed patch. Introducing new system of handling error 550 messages based on Benjamin's idea. So far only simple check if the target is directory has been implemented. Please review the patch, I especially don't like keeping references to GVfsBackendFtp and processed file in the FtpConnection object but it is the easiest way to do it. '2008-06-02 09:32:20' 'Benjamin Otte' The patch gets the gist of what I want, but it looks ugly in places. Here's what I think on how to solve those: My idea was that the error handlers should be implemented with simple ftp_connection_send() commands, that set errors automatically. So the is_directory handler would look something like this: static void error_550_is_directory (FtpConnection *conn, const FtpFile *file) { guint response = ftp_connection_send (conn, RESPONSE_PASS_500, \"cwd %s\", file); if (response == 550) { g_set_error (&conn->error, G_IO_ERROR, G_IO_ERROR_IS_DIRECTORY, _(\"File is a directory\")); } else if (STATUS_GROUP (response) == 5) { ftp_connection_set_error_from_response (conn, response); } } So we'd have a bunch of error handlers named error_550_$ERROR_WE_CHECK() like error_550_not_found or error_550_permission_denied that do some ftp sending magic to figure out specific things. While writing the above code, it occured to me that we might want to have a new flag \"RESPONSE_PASS_550\" just for the 550 error code, which would help in quite some cases and make the above function look like this: static void error_550_check_directory (FtpConnection *conn, const FtpFile *file) { guint response = ftp_connection_send (conn, RESPONSE_PASS_550, \"cwd %s\", file); if (response == 550) { g_set_error (&conn->error, G_IO_ERROR, G_IO_ERROR_IS_DIRECTORY, _(\"File is a directory\")); } } I also think that we want a seperate ftp_connection_send_and_check function, that does the job of doing special 550 checks, as there's a lot of cases where those aren't needed. The code would roughly look like this: typedef void (* Ftp550Handler) (FtpConnection *conn, const FtpFile *file); static void ftp_connection_check_file (FtpConnection *conn, const Ftp550Handler *handlers, const FtpFile *file) { while (*handlers && !ftp_connection_in_error (conn)) { handlers (conn, file); handlers++; } } static guint ftp_connection_send_and_check (FtpConnection *conn, ResponseFlags flags, const Ftp550Handler *handlers, const FtpFile *file, const char *format, ...) G_GNUC_PRINTF (5, 6) { va_list varargs; guint response; /* check that there's no 550 handling used - don't allow bad use of API */ g_return_val_if_fail (flags & | == 0, 0); g_return_val_if_fail (handlers != NULL, 0); g_return_val_if_fail (file != NULL, 0); va_start (varargs, format); response = ftp_connection_sendv (conn, flags | RESPONSE_PASS_550, format, varargs); va_end (varargs); if (response == 550) { ftp_connection_check_file (conn, handlers, file); response = 0; } return response; } This also solves the problem of having our 550 handling move into the response codes, which looks a bit unfortunate API wise. And we get rid of adding more members to the FtpConnection struct, especially those that don't belong there. Some smaller things: - The function was called \"error_550_check_directory\". That's a somewhat bad choice for a name, as I don't know if it checks whether the file is or is not a directory. - Please change the default error code for 550 to G_IO_ERROR_FAILED. \"Operation failed\" sounds much better than \"File unavailable\". And it tells us where we miss 550 checks: Whenever we get \"FAILED\" :) - Your patch includes the \"LIST -a\" change for bad directory listings. '2008-06-10 13:51:58' 'Tomas Bzatek' Created an attachment (id=112474) [details] gvfs-ftp-read-directory-2.patch Modified patch, fixing all issues noted in the previous comment. '2008-06-10 17:12:54' 'Benjamin Otte' From a quick review the patch looks pretty much like I imagined it. And before I forget it: error_550_is_directory() checks for 250, not 550. '2008-06-11 11:53:26' 'Tomas Bzatek' Commited slightly modified patch to trunk and stable 2.22 branch. This fixes recursive copy of directory structure in Nautilus. The delete issue reported in the first post might be related to bug #528347, where client apps using GIO/GVFS are unable see dot-files which are blocking directory removal as it's not empty. Otherwise deleting whole directory structure works fine in Nautilus and backend reports G_IO_ERROR_NOT_EMPTY correctly. '2001-11-10 11:32:37' 'Skip Montanaro' According to Havoc: If you need struct fields in any widget, please file a bug report, they should never be required to use a widget. Accordingly, I took a look at the places where the latest PyGtk wrappers directly access widget data attributes to provide needed functionality. I found 43 examples, identified in the table below. (Of course, there may be more that PyGtk doesn't use or expose.) Most of these data attributes are accessed directly to provide them to the Python programmer. I assume that means they would also have to be accessed directly by the C programmer. GTK_ADJUSTMENT lower GTK_ADJUSTMENT page_increment GTK_ADJUSTMENT page_size GTK_ADJUSTMENT step_increment GTK_ADJUSTMENT upper GTK_ADJUSTMENT value GTK_BIN child GTK_CHECK_MENU_ITEM active GTK_CLIST columns GTK_CLIST focus_row GTK_CLIST row_list GTK_CLIST rows GTK_CLIST selection GTK_COLOR_SELECTION_DIALOG cancel_button GTK_COLOR_SELECTION_DIALOG colorsel GTK_COLOR_SELECTION_DIALOG help_button GTK_COLOR_SELECTION_DIALOG ok_button GTK_COMBO entry GTK_COMBO list GTK_CURVE num_points GTK_DIALOG action_area GTK_DIALOG vbox GTK_FONT_SELECTION_DIALOG action_area GTK_FONT_SELECTION_DIALOG apply_button GTK_FONT_SELECTION_DIALOG cancel_button GTK_FONT_SELECTION_DIALOG fontsel GTK_FONT_SELECTION_DIALOG main_vbox GTK_FONT_SELECTION_DIALOG ok_button GTK_GAMMA_CURVE curve GTK_GAMMA_CURVE gamma GTK_GAMMA_CURVE gamma_dialog GTK_GAMMA_CURVE gamma_text GTK_GAMMA_CURVE table GTK_LIST selection GTK_NOTEBOOK tab_pos GTK_STYLE black GTK_STYLE white GTK_TEXT_BUFFER tag_table GTK_TOGGLE_BUTTON draw_indicator GTK_WIDGET allocation GTK_WIDGET parent GTK_WIDGET style GTK_WIDGET window '2001-11-10 18:43:15' 'Havoc Pennington' Thanks, this is helpful. Some of them are bogus and already have accessor functions, I believe: GTK_BIN child GTK_CHECK_MENU_ITEM active GTK_TEXT_BUFFER tag_table Also, most of them are for deprecated widgets. But there are many there we should probably have functions for. Adding API keyword, but putting on future milestone. '2001-11-11 09:56:51' 'Skip Montanaro' When considering accessor functions, you might also want to consider raising the API up to a bit higher level. For example, the Combo widget should probably have its own value-changed signal and direct access to the underlying entry and list widgets should be deprecated with some higher level functions written for the Combo widget to get at necessary functionality. Since the GtkList widget is already deprecated, this stuff is going to break in applications someday anyway. '2002-12-13 00:10:27' 'vilm0001' No kidding about the breakability in the combo box: this is already pretty much broken in GTK-- (C++ binding), where they use a different implementation for the (deprecated) list, which basically makes it impossible to access list data. A change in the GTK+ API to allow access to the list items through a function would make this a whole lot more usable. Suggestion: Make the list in the combo a GList. This would also make working with the combo easier... Not sure if there's a good way of handling arbitary widgets with associated text without creating some sort of ListItem (deprecated) replacement... '2008-07-15 06:42:14' 'Matthias Clasen' The ongoing gseal work is finally taking care of this. '2008-02-04 20:04:59' 'Jaap A. Haitsma' Currently apps use gnome_help functions to show help files, but gnome_help is part of the deprecated gnome_help See also GNOME goal proposal http://live.gnome.org/action/show/GnomeGoals/RemoveGnomeOpenGnomeHelp '2008-02-20 21:53:25' 'Jaap A. Haitsma' Created an attachment (id=105668) [details] Patch adding gtk_show_uri and gtk_show_help to GTK+ '2008-02-20 22:06:32' 'Christian Persch' The gtk_show_help function is missing |return ret;|. You forgot to add the new funcs to gtk/gtk.symbols . + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. There is no \"Lesser GPL version 2\". It's the Lesser GPL version 2.1 (or the Library GPL version 2). '2008-02-20 22:29:50' 'Sven Neumann' Somehow I feel that gtk_show_help() is too GNOME oriented to be included in this form. I have been told that gtk_show_uri() will work nicely on the major supported platforms. This is hwoever not the case for gtk_show_help(). Since the functionality of gtk_show_help() can be easily implemented on top of gtk_show_uri(), it should be sufficient to provide gtk_show_uri() for now. '2008-02-20 22:37:42' 'Jaap A. Haitsma' Created an attachment (id=105671) [details] Updated patch. Adding ret and gtk symbols Christian, I copied the license from other files in GTK+. I opened about 5 to 6 files and they are the same. I guess it's a better idea to change all licenses in one go '2008-02-23 17:33:56' 'Jaap A. Haitsma' What's the consensus on this? Can I commit gtkshow.c to gtk+ when I remove gtk_show_help? '2008-02-29 21:35:35' 'Bastien Nocera' Update your patch to remove gtk_show_help() to start with. '2008-02-29 22:31:44' 'Jaap A. Haitsma' Created an attachment (id=106302) [details] Patch removing gtk_show_help '2008-03-07 21:06:05' 'Jaap A. Haitsma' Can one of the maintainers decided what to do with this patch? Thanks '2008-03-16 21:03:09' 'Morten Welinder' gtk_show_uri allows a NULL parent, but that is not multi-head safe. Why not take a mandatory GdkScreen argument since the function couldn't care less about the parent widget beyond its screen? '2008-03-16 21:44:27' 'Jaap A. Haitsma' I can make it such that the parent has to be set mandatory. Having a GtkWidget *parent saves calling a gtk_widget_get_screen everytime you do a gtk_show_uri What's the opinion on this of others? '2008-03-16 22:22:12' 'Ross Burton' I don't think the parent should be mandatory, because there are situations where they may not be a parent at all. '2008-03-18 16:08:00' 'Sven Neumann' A mandatory parent would be bad, as Ross explained in comment #11. IMO the best solution is to change the function to take a GdkScreen instead of a parent widget. Shouldn't hurt much to call gtk_widget_get_screen(). '2008-03-23 23:12:30' 'Jaap A. Haitsma' Created an attachment (id=107888) [details] Updated gtk_show_uri patch now using a GdkScreen as input Thanks for you comments. Any more comments? '2008-04-04 05:54:02' 'Jaap A. Haitsma' Ping. Can above patch be applied? '2008-04-19 19:07:00' 'Jaap A. Haitsma' Can one of the maintainers make a decision about this patch. Thanks '2008-04-26 22:14:56' 'Matthias Clasen' Some comments: - Wrt to the parent issue, I think the function should accept NULL there. Being forced to call gdk_widget_get_screen() is annoyance, when GdkAppLaunchContext handles unset screen already. - The documentation needs to go in some more detail about what kind of 'uri' this function accepts. There is no standard for this, unfortunately, and the gnome-vfs->gio transition has unearthed a number of problems due to this. - I'd be interested in a function that mounts the volume before opening it. This is what e.g. the panel needs (see bug 529243 ). That could be a separate function, or gtk_uri_show could take flags. '2008-04-27 08:53:40' 'Jaap A. Haitsma' Created an attachment (id=109974) [details] Updated patch. GdkScreen can be NULL Matthias, thanks for the review. I've updated the patch with your first two comments. About the third comment (the auto mounting). Why would gtk_show_uri need extra flags for this? We could add code that just tries to mount if this is necessary. Your patch in bug 529243 uses libgnomeui/gnome-password-dialog.h which can't be used in gtk+ What do you want to do? Commit this patch (quite some apps could reduce their dependency on libgnomeui and friends already) and later on add the mounting part '2008-04-27 14:04:04' 'Morten Welinder' Matthias: being forced to call gdk_widget_get_screen is a good thing as it avoids multiscreen bugs. If GdkAppLaunchContext handles it, as you say, that sounds like that ought to be fixed too. There really is no way the gdk/gtk layer can know what screen should be used. '2008-04-27 16:09:36' 'Dan Winship' OK, this bug report has gotten silly.</monty-python> In 99% of use cases, the user interacts with some widget, and as a result, the program wants to show a URI on the same screen as that widget. In 99% of the remaining 1% of use cases, the program has no opinion at all about what screen to show the URI on (eg, gnome-open), and so it's going to pass NULL for parent regardless of whether parent is a GtkWidget or a GtkScreen. (Or in the mandatory GtkScreen case, it would always call gdk_screen_get_default().) Given that this is a 10-line function, it seems silly to make its interface less convenient for 99% of users just so it can cover an additional 0.01% of use cases. Assuming there actually are programs that need to show URIs on specific screens that do not correspond to any live widget, the developers of those programs can just cut and paste the gtk_show_uri source and change it accordingly. accordingly. '2008-05-25 03:41:11' 'Matthias Clasen' Jaap: the way to handle mounting in GTK+ is to use a GtkMountOperation. I'm not 100% happy with the single-function header gtkshow.h, but I don't really have a better alternative. It is probably ok to commit it in this form now, we'll figure out the mounting later. '2008-05-25 08:51:41' 'Jaap A. Haitsma' Thanks for the review. It's now committed 2008-05-25 Jaap A. Haitsma <jaap@haitsma.org> reviewed by: Matthias Clasen * gtk/Makefile.am: * gtk/gtk.h: * gtk/gtk.symbols: * gtk/gtkshow.c: (gtk_show_uri): * gtk/gtkshow.h: Add gtk_show_uri to make showing uris really easy. Fixes bug #514396 '2008-01-18 20:59:00' 'Daniel' Created an attachment (id=87317) [details] the error report I'm using the SWT library, ran the \"Hello World\" example: import org.eclipse.swt.widgets.*; public class SWTExperiment { public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell(display); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } } and SWT fails to load, it always exits with java has exited due to signal 4 (SIGILL). I see the window flash open, then immediately it crashes. There is nothing in the logs. when i open the resulting jar with the jar launcher I get the crash report which I attached. '2008-01-18 21:03:33' 'Daniel' also, I ditched the new version and tried 3.2.2 and it worked '2008-04-11 18:01:42' 'McQ' On my Mac, running OS X 10.5.2, I successfully ran the hello world example, from the command line, using the SWT from R3.4 M6. Can you try that version and see if it fails for you? Also, can you run java -version and let us know what it prints? '2008-04-11 19:45:17' 'Daniel' this is the output from java -version java version \"1.5.0_13\" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) I'm running Mac OS X 10.4.11, so still on Tiger. I ran it again with the R3.4 M6 (including swt-debug.jar) and i'm getting the same issue, seeing the frame and then crashing with SIGILL. '2008-04-11 20:12:25' 'McQ' Adding Steve to increase the visibility. '2008-04-14 10:31:01' 'Kevin Barnes' How are you launching your app? If you are launch from the command line, are you using the -XstartOnFirstThread option? (http://www.eclipse.org/swt/faq.php#carbonapp) I'm running on leopard w/o any problems. I'll try Tiger. '2008-04-14 11:15:48' 'Kevin Barnes' Sorry, I could not reproduce this on Tiger either. I tried running in Eclipse, from command line, and exporting a project as a runnable jar from Eclipse. No crashes. Please provide detailed instructions on how you are creating your project and running you code. '2008-04-14 15:37:50' 'Daniel' I created it using xcode 2.5 on tiger. I tried using eclipse but it would not build from source for some reason, so thats how i ended up on xcode. There are no command line arguments except -cp SWTexperiment.jar SWTexperiment, which doesn't pertain to this. I just tried adding the -XstartOnFirstThread option and everything worked fine. No crashing, everything is wonderful. what does this option do? '2008-04-14 16:04:19' 'Steve Northover' http://www.eclipse.org/swt/faq.php#carbonapp '2004-07-06 06:31:00' 'lucas bigeardel' Group title is not taken into account by Window-Eyes 4.5. The group title should be pronouced before radio buttons or other controls. It is not, this is bug since blid users cannont know what the group content is dealing about. '2004-08-23 17:50:11' 'Carolyn MacLeod' Interesting. Both Window-Eyes and JAWS will read a Group title IF the Group has a single child that does not have an obvious name, for example, a text or a list or a combo box. But neither screen reader will read a Group title if it groups a set of radio buttons or check boxes, say. (Or, I assume, if it is surrounding something that has an obvious label to read instead, like a button, and if the child control takes focus). We have several dialogs - notably, the search and find/replace dialogs, that have groups with radio/checkbox children. The screen readers do not read the group titles in these dialogs. I will bring this to the attention of the screen reader developers. For now, an extreme, but sort-of useable work-around in Window-Eyes is to tell it to read every control in a newly-opened dialog. You can do this with: Global -> Verbosity -> Activated... Entire Window if Dialog '2004-08-27 02:37:16' 'Carolyn MacLeod' CCing Frank and Lin. Here are 2 examples of eclipse dialogs where a group title is not read: 1) Click on the flashlight (Search) tool in the main toolbar. Click on any of the tabs in the notebook. All of the pages have a \"Scope\" group. Some of the pages have a \"Search For\" group or a \"Limit To\" group. None of these titles are read by JAWS. 2) Open an editor on any file, and then select Edit -> Find/Replace... (or type ctrl+F) to get the Find/Replace dialog. The \"Direction\", \"Scope\", and \"Options\" group titles are never read. I think the best thing would be if these were read when one of the radio or checkbox controls gets focus (i.e. when the dialog is activated, and when the user tabs to a new group or clicks on a control in another group. '2004-08-31 15:40:47' 'Lin Ma' Today, Frank and Lin tested with JAWS 5.0, 5.1 and 6.0 beta, we found both the dialogue from flashlight and Find/Replace from the Edit group titles are spoken correctly. '2004-09-01 16:55:52' 'Carolyn MacLeod' Created an attachment (id=14333) [details] GroupTests.java It is not working for me, so either I didn't make the problem clear enough, or you have some JAWS settings set that I do not have set. I just installed JAWS 5.1, and in the installation process, it asked if I wanted to keep settings from my previous JAWS version. I said \"No\", because I want my JAWS 5.1 to be \"out-of-the-box\". So I have NO settings in my JAWS 5.1, so no surprises. I will attach a little code snippet here that shows the problem very simply. Copy the attachment into your snippets directory, refresh your snippets project, select GroupTests.java, and Run -> Java Application. What I hear when I tab or down/up arrow is \"green\" or \"blue\", depending on who has focus. What I want to hear is \"Foreground - green\" and \"Background - blue\". '2004-09-08 11:25:35' 'Carolyn MacLeod' Created an attachment (id=14443) [details] GroupTests.java Sorry - Bugzilla defaulted to saving the java file as octet-stream, which isn't very useful. I am attaching it again, and specifying type \"text\". Please ignore the previous attachment and get this new one. '2004-09-28 15:50:14' 'Frank DiPalermo' Carolyn, Sorry, but I used your code snippet and I do indeed hear the group box names along with the individual radio buttons. I am using JAWS 5.1.383. '2004-10-07 16:38:14' 'Carolyn MacLeod' I am also using JAWS 5.10.383, and I still don't hear \"Foreground\" or \"Background\". we must have different settings somehow. I will attach my default.jcf (I believe that it is \"straight from the factory\". I do not have a javaw.jcf. Maybe we can figure out what setting you have set that I don't have set. '2004-10-07 16:39:51' 'Carolyn MacLeod' Created an attachment (id=15052) [details] C:\\JAWS510\\SETTINGS\\enu\\Default.JCF '2004-10-15 15:34:37' 'Carolyn MacLeod' After further investigation, we determined that the problem only happens on Windows XP with the javaw.exe.manifest installed in jre/bin (this tells WinXP to use the WinXP common controls - version 6.0 - instead of the Win2K common controls - version 5.x). '2004-12-13 10:19:05' 'Frank DiPalermo' This problem is solved in JAWS. The window class for this object has been reassigned internally in JAWS. This fix will be reflected in JAWS version 6.0 which is due out shortly. '2005-04-13 17:03:08' 'Carolyn MacLeod' Verified that this now works in JAWS 6.0. Thank-you, Frank! '2005-04-13 17:04:24' 'Carolyn MacLeod' *** Bug 51963 has been marked as a duplicate of this bug. *** '2008-01-31 16:17:19' 'lucas bigeardel' close '2008-04-11 10:14:00' 'Manfred Hahn' Hi Martin, after installation of Teneo the entry \"Ant Home Entries (Default)\" on the classpath page of Preferences->Ant->Runtime is empty (though the child entries of this tree node are visible). In addition to this I get a lot of NullPointerExceptions in the .log with \"Malformed URL\" as Message when I open that preference page. The stack does not show any participation of teneo. I tested it on a complete new eclipse (RCP version) installation (M20080221-1800 ) with the EMF, GEF and GMF features installed in an empty workspace. After each installation I looked at the that \"Ant Home Entries\" entry and all was fine. But after installation of teneo it vanished. After disabling of the teneo plugin the entry is visible again. gr. Manfred '2008-04-11 13:51:49' 'Martin taal' Hi Manfred, This seems strange behavior as installing teneo should not interfere with the rest of the eclipse installation. Teneo is really just a set of plugins which do not change other plugins. Can you remove .log file and then restart eclipse with the -clean option and then attach the resulting .log file to this bugzilla? In addition which versions of eclipse, emf, etc. are you using? Can you also attach a screendump of the strange thing you see in preferences/ant? Does the plugin/feature information say something special? You can find it here: Help/Software Updates/Manage Configuration note that this view has a button to hide non-loaded features/plugins. Can you see which plugins fail to load? Depending on the version of eclipse you can see some more details of why the plugin failed to load. gr. Martin '2008-04-11 15:54:22' 'Manfred Hahn' Created an attachment (id=95747) [details] log-file with errors after opening Ant Runtime Preferences '2008-04-11 15:55:45' 'Manfred Hahn' Created an attachment (id=95748) [details] Ant Runtime Preferences screenshot '2008-04-11 15:57:22' 'Manfred Hahn' Created an attachment (id=95749) [details] Configuration from Software Updates/Mangage Configuration '2008-04-11 16:03:39' 'Manfred Hahn' Hi Martin, I have made the complete new configuration today and have added each new feature with the update manager. Perhaps this is a case that belongs to the core team of eclipse? gr. Manfred '2008-04-11 16:15:42' 'Manfred Hahn' Hi Martin, as you see from the .log-file I forgot the -clean flag. Now I did it, but the .log-file only differs in that this setting is now shown. All other messages including that curious \"Invalid perference page: Cache\" are the same. gr. Manfred '2008-04-11 19:53:34' 'Martin taal' Hi Manfred, Yes I can really not think on how this can be caused by Teneo. I have moved the issue to the platform project. Can you post a topic on the platform newsgroup (with a link to this bugzilla)? Maybe they know right away what's wrong. gr. Martin '2008-06-25 02:39:26' 'Manfred Hahn' This behaviour did vanish with the teneo version I200805200858. I believe there had been a consolidation of used libraries. Because of this I set set the resolution to fixed. '2009-05-13 12:37:00' 'Kevin Barnes' The releng test have been DNF for the last couple builds. Running locally we occasionally see crashes in the BrowserTests so we suspect these crashes to be the cause of the DNF. '2009-05-14 16:02:09' 'Silenio Quarti' Created an attachment (id=135853) [details] '2009-05-14 16:09:22' 'Kevin Barnes' Pushing this fix for RC2, as it's too risky to make this change for RC1 now. For RC1 we'll comment out the crashing tests so that the other tests can run properly. We have NOT seen this bug affect the usability of Eclipse, only the running of the SWT test suite. '2009-05-14 16:17:14' 'Silenio Quarti' The problem is that the strategy we use to release pools periodically (in readAndDispatch, createWidget, etc) to be able to run the test suites, releases the main thread pool created be Device and stored in a thread local dictionary. The pool was not removed from the thread local dictionary and got reused the next time a display was created. The new strategy is to only release the main thread pool when the device count goes to zero. '2009-05-15 07:09:33' 'McQ' Obviously, something this low level needs as much testing as it can get. Can we get a test build run to verify all tests pass/no crashes/no OOM/etc? Also, you should be doing the two day test pass on a version of SWT that includes the change. '2009-05-15 17:38:24' 'Silenio Quarti' Created an attachment (id=136083) [details] new fix '2009-05-15 17:54:40' 'Silenio Quarti' The new fix is simpler, we just make sure the the pool in the thread dictionary is always valid, that way when another display is created it will not use a released pool. There was a further problem where the pool was released too early. If we are in call in, we cannot released the top of the stack pool. '2009-05-15 17:58:28' 'Silenio Quarti' The tests that where showing this problem have been put back (just in HEAD). Fixed > 20090515 '2008-04-15 06:53:44' 'Wolfgang Sourdeau' User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr-FR; rv:1.8.1.13) Gecko/20080311 Iceweasel/2.0.0.13 (Debian-2.0.0.13-1) Build Identifier: 0.8 (2008033118) When a calendar to which I am subscribed no longer exists, Lightning will try indefinitely to reach it and use 100% of my CPU. This, despite the 404 results it receives. Reproducible: Always Steps to Reproduce: 1. create a calendar on your server 2. subscribe to it via Lightning 3. quit Thunderbird 4. erase the calendar from your server 5. relaunch Thunderbird Actual Results: A propfind is executed on the resource, resulting in a 404 error code. An OPTION on the parent directory occurs, with a 200 result. Then the loop continues with a new propfind... Expected Results: I would expect Lightning to stop trying to reach the calendar collection as soon as it receives the 404 result. Here is a trace of what happens (obtained with tcpflow): PROPFIND /SOGo/dav/wsourdeau/Calendar/1D52AE6B-8564-0001-6A40-17B089902560/ HTTP/1.1 x-webobjects-server-protocol: HTTP/1.1 x-webobjects-remote-addr: 127.0.0.1 x-webobjects-remote-host: 127.0.0.1 x-webobjects-server-name: localhost x-webobjects-server-url: http://localhost Host: localhost User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12 Accept: text/xml Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip ,deflate Accept-Charset: utf-8,*;q=0.1 Keep-Alive: 300 Connection: keep-alive Content-Length: 86 Content-Type: text/xml; charset=utf-8 Depth: 0 <D:propfind xmlns:D=\"DAV:\"> <D:prop> <D:resourcetype/> </D:prop> </D:propfind> HTTP/1.0 401 Authorization Required content-length: 0 www-authenticate: basic realm=\"SOGo-0.9\" PROPFIND /SOGo/dav/wsourdeau/Calendar/1D52AE6B-8564-0001-6A40-17B089902560/ HTTP/1.1 x-webobjects-server-protocol: HTTP/1.1 x-webobjects-remote-addr: 127.0.0.1 x-webobjects-remote-host: 127.0.0.1 x-webobjects-server-name: localhost x-webobjects-server-url: http://localhost Host: localhost User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12 Accept: text/xml Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip ,deflate Accept-Charset: utf-8,*;q=0.1 Keep-Alive: 300 Connection: keep-alive Content-Length: 86 Content-Type: text/xml; charset=utf-8 Depth: 0 Authorization: Basic hidden <D:propfind xmlns:D=\"DAV:\"> <D:prop> <D:resourcetype/> </D:prop> </D:propfind> HTTP/1.0 404 Not found content-length: 85 content-type: text/html object not found: wsourdeau => Calendar => 1D52AE6B-8564-0001-6A40-17B089902560 PROPFIND /SOGo/dav/wsourdeau/Calendar/1D52AE6B-8564-0001-6A40-17B089902560/ HTTP/1.1 x-webobjects-server-protocol: HTTP/1.1 x-webobjects-remote-addr: 127.0.0.1 x-webobjects-remote-host: 127.0.0.1 x-webobjects-server-name: localhost x-webobjects-server-url: http://localhost Host: localhost User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12 Accept: text/xml Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip ,deflate Accept-Charset: utf-8,*;q=0.1 Keep-Alive: 300 Connection: keep-alive Content-Length: 86 Content-Type: text/xml; charset=utf-8 Depth: 0 Authorization: Basic hidden <D:propfind xmlns:D=\"DAV:\"> <D:prop> <D:resourcetype/> </D:prop> </D:propfind> OPTIONS /SOGo/dav/wsourdeau/Calendar/ HTTP/1.1 x-webobjects-server-protocol: HTTP/1.1 x-webobjects-remote-addr: 127.0.0.1 x-webobjects-remote-host: 127.0.0.1 x-webobjects-server-name: localhost x-webobjects-server-url: http://localhost Host: localhost User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12 Accept: text/xml Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: utf-8,*;q=0. 1 Keep-Alive: 300 Connection: keep-alive HTTP/1.0 404 Not found content-length: 85 content-type: text/html object not found: wsourdeau => Calendar => 1D52AE6B-8564-0001-6A40-17B089902560 HTTP/1.0 401 Authorization Required content-length: 0 www-authenticate: basic realm=\"SOGo-0.9\" OPTIONS /SOGo/dav/wsourdeau/Calendar/ HTTP/1.1 x-webobjects-server-protocol: HTTP/1.1 x-webobjects-remote-addr: 127.0.0.1 x-webobjects-remote-host: 127.0.0.1 x-webobjects-server-name: localhost x-webobjects-server-url: http://localhost Host: localhost User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12 Accept: text/xml Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: utf-8,*;q=0. 1 Keep-Alive: 300 Connection: keep-alive OPTIONS /SOGo/dav/wsourdeau/Calendar/ HTTP/1.1 x-webobjects-server-protocol: HTTP/1.1 x-webobjects-remote-addr: 127.0.0.1 x-webobjects-remote-host: 127.0.0.1 x-webobjects-server-name: localhost x-webobjects-server-url: http://localhost .... [ad finitum] '2008-04-15 06:55:10' 'Wolfgang Sourdeau' When using the display of source and destination ip/port in tcpflow, I notice the Lightning side always has a different port, which leads me to think that many connections are occuring at the same time. '2008-11-29 08:10:54' 'Ludovic Marcotte' The problem occurs when safeRefresh() is called from calDavCalendar.js. In there, we have the following condition: if (!this.mCtag || !this.mFirstRefreshDone) { var refreshEvent = this.prepRefresh(); this.getUpdatedItems(refreshEvent, aChangeLogListener); return; } this.mFirstRefreshDone is false because since the calendar was removed, we never got a chance to complete the call to getCalendarData() nor checkDavResourceType() (see https://bugzilla.mozilla.org/show_bug.cgi?id=463961 for that one...). So, we'll enter into an infinite loop because getUpdatedItems() calls right at the beginning checkDavResourceType() since the calendar was marked as disabled. But, checkDavResourceType() doesn't check for the 404 error code. We have: var str = convertByteArray(aResult, aResultLength); if (!str) { dump(\"CalDAV: Failed to determine resource type\"); thisCalendar.completeCheckServerInfo(aChangeLogListener, Components.interfaces.calIErrors.DAV_NOT_DAV); return; } else if (thisCalendar.verboseLogging()) { dump(\"CalDAV: recv: \" + str); } and we should rather have something like: var str = convertByteArray(aResult, aResultLength); if (!str || aContext.responseStatus == 404) { dump(\"CalDAV: Failed to determine resource type\"); thisCalendar.completeCheckServerInfo(aChangeLogListener, Components.interfaces.calIErrors.DAV_NOT_DAV); return; } else if (thisCalendar.verboseLogging()) { dump(\"CalDAV: recv: \" + str); } This cause checkDavResourceType() to (incorrectly) continue its processing, which will cause a call to completeCheckServerInfo() with a success code and then again, a call to safeRefresh(), creating an infite loop for cached calendars. '2009-02-22 08:16:09' 'Ludovic Marcotte' Created an attachment (id=363577) [details] Proposed fix This bug is critical in order to avoid an endless loop and also in order to avoid generating _tons_ of HTTP requests to the CalDAV server (up to 10-20 per second). '2009-02-22 09:01:13' 'Philipp Kewisch' (From update of attachment 363577 [details]) Looks good, r=philipp. I've added another completeCheckServerInfo further above since calling request.responseStatus if there was some sort of request error causes it to throw. This is caught further above, but if we use it again here then we should break out earlier. '2009-02-22 09:02:30' 'Philipp Kewisch' Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/7e4da21b2924> -> FIXED '2007-11-15 08:24:07' 'Jean-Michel Reghem' For some time (2 months? more?, i don't remember) i have this problem: --> if i drag and drop a folder from a location to an other, cpu use for thunderbird process is more than 50%. --> Even if the folder is empty --> It occurs with subfolder move inside Local Folders --> It occurs with folder move inside a pop account (for example moving Inbox->test to Draft->test --> It DOESN'T occurs when moving a folder from a pop account to an other (for example moving AccoutA --> Inbox --> test to AccountB --> Inbox -->test ... Butin this case, by design, folder is copied, not moved --> it seems that this is the delete which is the problem Other Facts ============ - Memory doesn't change during the move time ... only a high level of cpu use - Delete key or Right-click delete (so move to trash) got the same bad result - Renaming a folder take a long time too - Checking pop account take more resources than before ... 10 to 20\" of high cpu resource for checking mail, slowing a lot of windows applications - Same thing for RSS folders ... Hardware and Software information ================================= Computer: Dell Latitude D820 laptop, Core 2 Duo 2GHz, 2Go Ram, 100Go HD 7200rpm OS: Windows Vista Business Thunderbird: TB nightly 2.0.0.10pre (2007111403) ... but problem occurs since long time Profile: profile.ini modified to have the profile files on D:\\Thunderbird\\JMR.profil. All emails account store on D:\\Thunderbird\\ (13 pop account + 69 RSS feeds) D:\\Thunderbird: 2.3Go Bigger file: 384Mo Configuration: each pop has its own folder (inbox, etc ...) but rules filters lot of mails to subfolder in local folder directory I've check bugzilla for similar bug, event Mozillazine forum, but never seen something like this '2007-11-15 08:24:43' 'Jean-Michel Reghem' Additional information: Running in safe mode: same problem '2007-12-04 00:58:00' 'Jean-Michel Reghem' ohoh ... thus bug seems related to my 10000 temp files in temp folder: tmprules-xxx.dat I've deleted all of them --> filters works again AND this bug seems solved by removing them bad news: new tmprules begin to appairs ... So, this bug is a dup of bug 362539 *** This bug has been marked as a duplicate of bug 362539 *** '2007-12-04 01:10:41' 'Jean-Michel Reghem' I guess the really low perf behaviour was coming that TB parsed all 10000 rules files for all received mail ... same thing when moving a folder, it parsed the 10000 rules files to see if these have to be updated after the move '2007-12-04 07:56:21' 'RDL' (In reply to comment #2) > ohoh ... thus bug seems related to my 10000 temp files in temp folder: tmprules-xxx.dat > > I've deleted all of them --> filters works again AND this bug seems solved by removing them > > bad news: new tmprules begin to appairs ... > > So, this bug is a dup of bug 362539 > > *** This bug has been marked as a duplicate of bug 362539 *** > This bug is not a duplicate of bug 362539. Reason: 1) Although the underlying cause may be the same, the symptoms of the two bugs are very different. 2) Since the description attached to bug 362539 does not include the symptoms of this bug, it does not properly include this reported problem. 3) When users search for this problem, now that this bug is closed, they probably will not find this description. Nor will they find bug 362539 since it does not include these symptoms at the top level. Hence they will not find the circumvention. 4) Therefore, please re-open this bug report. 5) Please do not attempt to amend the description of bug 362539. Please leave that decision, as well as that of closure, to one of the Bugzilla 'monitors' who will know whether that is appropriate and, if so, how to do it cleanly, without obscuring user access to information. '2007-12-04 12:44:15' 'Jean-Michel Reghem' you're right ... this bug depends of 362539 and not a dupe '2007-12-04 13:06:50' 'RDL' (In reply to comment #5) > you're right ... this bug depends of 362539 and not a dupe > Thank you. '2008-01-08 02:24:19' 'WADA' Adding \"tmprules-N.dat\" in bug summary, for ease of search & understanding bug. (It looks to be too long. Please modify to appropriate one.) '2008-01-17 02:43:21' 'Jean-Michel Reghem' Resolved fixed as bug 375292 is fixed on branch 1.8 and trunk '2008-11-17 11:29:04' 'Wayne Mery' *** Bug 410739 has been marked as a duplicate of this bug. *** '2005-06-04 17:11:09' 'Elliotte Rusty Harold' User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;rv:1.8b2) Gecko/20050528 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;rv:1.8b2) Gecko/20050528 Firefox/1.0+ The folders pane in Thunderbird that lists my e-mail accounts and local folders does not allow me to select several folders at once. For instance I should be able to click on my James folder to select it, shift-click on my John folder to select it without deselecting the James folder, and then drag them *both* into my Friends folder. Currently I have to do this one at a time. Reproducible: Always Steps to Reproduce: 1. Click on a local folder 2. Shift-click on a different local folder Actual Results: The first folder is deselected. Expected Results: Kept both selected. Possibly there's a difference here between shift and command-clicking (on a Mac). Shift click should perhaps select everything between the clicked folder and the currently selected folder. Command-clicking normally selects only the folders you explicitly click on. Possibly there are other conventions on other platforms for multiple selections. But multiple selections should be possible, '2005-09-27 01:50:03' 'Gervase Markham' This is an automated message, with ID \"auto-resolve01\". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/ '2005-09-29 04:39:24' 'Mike Cowperthwaite' *** Bug 310352 has been marked as a duplicate of this bug. *** '2005-09-29 04:40:42' 'Mike Cowperthwaite' Suite bug 50767. '2006-11-07 08:49:32' 'Rob Campbell' This is highly-desirable in my opinion. I would like to see this implemented for easier management of RSS subscriptions. '2007-01-12 08:49:07' 'Magnus Melin' *** Bug 366757 has been marked as a duplicate of this bug. *** '2007-02-06 09:26:27' 'SteveC' I would love to see this closed, and also dragging up and down the folder pane much faster. '2007-10-09 09:48:18' 'Magnus Melin' *** Bug 398712 has been marked as a duplicate of this bug. *** '2007-11-19 03:01:54' 'Alex Deriziotis' This is pretty basic stuff. It's been a bit of a showstopper when migrating Outlook users over to Thunderbird since heavy users often have tons of folders to organise their emails. Importing their mail just dumps these folders into Local Folders and then they can't be re-organised in their inbox without going through them all one-by-one, which is just silly. '2008-10-31 01:24:22' 'Przemyslaw Bialik' On latest trunk multiple folders can be selected but there is completely no benefit of it: on drag and drop only 1 folder is moved, CM shows only 3 entries (open, open in new tab, properties) and even they are useless ;) (nothing happens / empty tab). Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081030 Lightning/1.0pre Shredder/3.0b1pre '2008-10-31 01:41:22' 'Przemyslaw Bialik' blocking‑thunderbird3 ? Multiple selection should be either useful or not possible at all. '2008-11-11 11:36:55' 'Przemyslaw Bialik' Adjusting description. '2008-11-12 11:09:52' 'Magnus Melin' Marking as regression as in 2.0 you couldn't select more than one folder at a time. '2008-12-20 05:20:22' 'Magnus Melin' Would be great if someone went through and made context commands work where it should, but at the very least we should make commands unavailable when they won't work anyway. blocking-tb3+ to at least get the minimal fix in. '2009-01-21 22:44:54' 'David Ascher' Magnus, care to own this bug? '2009-02-08 11:47:06' 'Magnus Melin' Sure, though if someone want's to take it on it's up for grabs. '2009-03-03 02:10:00' 'Mark Banner' *** Bug 481159 has been marked as a duplicate of this bug. *** '2009-04-13 22:29:25' 'Bryan W Clark' I'll put this up for m5 since it's not active right now '2009-04-25 12:08:51' 'Magnus Melin' Created an attachment (id=374607) [details] proposed fix The items that I think make sense for multi select: Get Messages o if only servers, or it's only newsgroups/feeds Open o though I question that we should have this item *at all* Open in new Tab Unsubscribe o if it's newsgroups only Delete o would have been useful, but the confirmation dialogs are not in js, we have multiple delete models etc so i gave up and just disabled it for multi selection Compact Mark Folder/s Read Mark Newsgroup/s Read --- Other notes: - hitting delete on ng to unsubscribe was broken (confirmUnsubscribe vs ConfirmUnsubscribe) - new saved search wasn't enabled for news - but you can create one - moving away from GetSelectedMsgFolders() to gFolderTreeView.getSelectedFolders() Still to do (maybe in another bug...): - fix tools menu folder commands - drag'n'drop (disable for multi?) --- Phil: got bandwidth for this? '2009-04-26 12:32:57' 'Phil Ringnalda' (From update of attachment 374607 [details]) Looks good to me, except >+ * Compacts either or all folders for accounts that the given folders belong to, or for accounts of the currently selected folders. That's hard enough to parse even without the stray or in \"either or\" ;) '2009-05-07 14:21:40' 'Bryan W Clark' (From update of attachment 374607 [details]) sounds good from the description '2009-05-08 17:52:17' 'Bryan W Clark' I was going to add the checkin-needed keyword but you probably want to fix the nits first '2009-05-09 05:07:46' 'Magnus Melin' changeset: 2593:2f6ef8daa83e http://hg.mozilla.org/comm-central/rev/2f6ef8daa83e ->FIXED Note to testers: now that this landed the commands of the folder context menu should work for multiple folders, if the are shown (and enabled). There's a lot of different possible combinations of folders/servers of different kinds possible so it would be good if people could make sure all cases work as they should for them. '2007-12-01 13:53:43' 'Josep Febrer' While using Alt+Tab for switching between applications works fine in my KDE4 post RC1 version, when I try to use Alt+Shift+Tab shortcut the keyboard did not respond anymore and I don't know how to get it back. However the mouse it is still working properlly, so I can logout with the mouse and I when I log back the keyboard it also works. '2007-12-05 17:41:05' 'Andreas Pakulat' I just hit this bug as well. But unfortunately I can't re-trigger it at the moment. While alt-shift-tab doesn't do anything here, the keyboard is still accessible. '2007-12-05 22:28:30' 'Andreas Pakulat' This is really a serious problem. It seems that if I hit Alt+Shift+tab directly I always get the problem. And if I just hit Alt+Tab and then Alt+Shift+tab and release I get it as well, so I have to make sure I always hit Alt+Tab as last thing. '2007-12-06 23:06:22' 'Matt Williams' In KDE 3, Alt+Shift+Tab is one of the possible shortcuts used for switching keyboard layouts (keyboard layout kcm -> xkb options -> layout switching tree item). Even though I don't have that box ticked, it still persists in changing the layout with that shortcut. Perhaps, the shortcut is being sent to the same place but is causing a crash due to some bitrot? '2007-12-06 23:46:31' 'Andreas Pakulat' While editing kglobalaccelsrc to change the shortcut does help, killing kxkb doesn't help at all and thus I don't think its kxkb causing the problem. '2007-12-06 23:47:54' 'Andreas Pakulat' *** Bug 153495 has been marked as a duplicate of this bug. *** '2007-12-07 00:18:11' 'Gaël de Chalendar' I confirm. I had to reboot. Note that the mouse was behaving has if the Shift key was pressed: it was extending the selection when clicking with the left button. '2007-12-08 20:23:44' 'Andreas Pakulat' The problem is in KGlobalAccel, it doesn't release the grab when a shortcut is set that isn't triggered. Which is the case for Alt+Shift+Tab, the shortcut that is actually send by X11 is Alt+Shift+Backtab. Re-Assigning. '2007-12-09 23:24:50' 'Matt Williams' *** Bug 153754 has been marked as a duplicate of this bug. *** '2007-12-11 11:27:41' 'Andreas Pakulat' SVN commit 747205 by apaku: Add a hotfix for Bug #153211, also ungrab the keyboard when Alt+Shift+Backtab was hit CCBUG:153211 M +5 -1 kglobalaccel_x11.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=747205 '2007-12-12 11:20:13' 'Josep Febrer' Thanks, your hotfix fixed this problem, however on the past KrushDay someone mentioned a similar issue pressing Alt+PrintScr which is still present for me. I don't know if this is related with the original issue, but if not you can close this bug. '2007-12-12 12:03:33' 'Andreas Pakulat' It could be, I'll check later today. IIRC Alt+Print Screen is some snapshot function right? You can easily check wether its the same issue by doing the following: Open $HOME/.kde4/share/config/kglobalshortcutsrc and find the action there. Then open any shortcut dialog in any application and change one of the shortcuts. When you're asked for pressing the new keyboard combination press the Alt+Print keys and check wether the label of the shortcut button is now the same as that in the rc-file. If they differ its the same problem and that means we need a different fix for this problem, than the hotfix I comitted. '2007-12-12 13:48:56' 'Josep Febrer' In kglobalshortcutsrc I have assigned Alt+Print to kwin, and also Alt+Shift+Tab to kwin. But if in one application like Konqueror or Konsole I assing a new shortcurt to Alt+Print it get's changed automatically to Alt+Shift+Print, so I can't assign another Alt+Print shortcut. However I can assign Alt+Shift+Tab shortcut, but besides it is still showing it in shortcut settings it doesn't work, and also it doesn't appear in kglobalshortcutsrc apart from the old one already existing and assigned to kwin. Also I don't know if is my setup but in 'kcmshell4 keys' I can't modify any shortcut, in fact, it doesn't show any, but that can be another bug. '2007-12-12 14:02:30' 'Andreas Pakulat' Ok as far as I can see this is the same problem, namely that the keys Alt+Print don't produce the X11 keysequence that is expected. In particular Alt+Shift+Tab creates a Qt key sequence of Alt+Shift+Backtab and seemingly Alt+Print creates Alt+Shift+Print in Qt key sequence. So this is indeed the same problem. Regarding the keys kcm: Thats \"expected\", the kcm hasn't been properly ported. I've already posted a patch for a minimal port to the kde-core list. That one will get comitted next monday, unless I get objections. '2007-12-12 16:21:52' 'Josep Febrer' I discovered another similar shortcut which is Ctrl+PrintScrn but this doesn't suffer this problem and works as expected. To my knowledge, only Alt+Shift+Print and Alt+Print are triggered by this bug. '2007-12-29 21:26:29' 'Andreas Pakulat' *** Bug 154692 has been marked as a duplicate of this bug. *** '2008-01-18 09:43:38' 'Andreas Pakulat' *** Bug 156069 has been marked as a duplicate of this bug. *** '2008-01-18 18:27:22' 'Lubos Lunak' SVN commit 763132 by lunakl: Since calling directly Xlib's XGrabKeyboard() is very unlikely and even probably undesired in kded, make KGlobalAccel again ungrab when there's no Qt caused grab. BUG: 153211 M +0 -7 kdedglobalaccel.cpp M +1 -4 kdedglobalaccel.h M +11 -11 kglobalaccel_x11.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=763132 '2008-01-23 19:38:13' 'Andreas Pakulat' *** Bug 156434 has been marked as a duplicate of this bug. *** '2009-01-05 22:47:48' 'Mathieu Jobin' this bug should still be open. I am running 4.2 beta 2 and this problem is still there. '2009-02-12 10:52:27' 'Mikael Gerdin' I've found this bug in KDE 4.2 too. I don't know if there is any specific key-combination that triggers it, but KWin acts as if I'm holding down the ALT-key, moving windows when I click and drag in them. (Kubuntu 8.10 (intrepid) packages from kubuntu-experimental) '2003-07-15 10:43:37' 'Rüdiger Koch' Version: (using KDE KDE 3.1KDE 1.2) Installed from: SuSE RPMsSuSE RPMs Sniff allows to find all locations from where a selected function is called. KDevelop already allows to 'grep foo(' in the context menu of the class treeview. While this feature doesn't work for me at all it would not do a good job since: 1. It finds calls of the same function name belonging to a different class 2. It doesn't find calls of functions if there are whitespaces between the function name and the left bracket such as foo->bar (); 3. It doesn't distinguish between overloaded functions '2003-07-15 10:57:47' 'Amilcar do Carmo Lucas' It would be nice to know your KDevelop version! '2003-07-15 11:47:28' 'rkoch@rkoch.org' Subject: Re: find callers of functions version 2.1.3. Sorry if the feature is in a newer version of KDevelop (3.0) but nothing in the changelog suggests that. -Rudiger --- Amilcar do Carmo Lucas <a.lucas@tu-bs.de> wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=61263 > a.lucas@tu-bs.de changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Component|general |classview > > > > ------- Additional Comments From a.lucas@tu-bs.de 2003-07-15 10:57 > ------- > It would be nice to know your KDevelop version! '2003-07-15 12:01:54' 'Amilcar do Carmo Lucas' Sorry, KDevelop 2.x is no longer under development. You are strongly advised to update to the latest CVS version of KDevelop3, code name gideon, take a look at: http://www.kdevelop.org/index.html?filename=branches_compiling.html for all the details you need. If you find a problem or need help please send a mail to the mailing list: http://www.kdevelop.org/index.html?filename=mailinglist.html or drop us a line at the channel #kdevelop on the server irc.kde.org using ksirc, for example. Please use the CVS version and compile it yourself because that way you can easily patch it if a bug is found. KDevelop3 can open Develop2 projects. To do so, goto the \"Project -> Open Project ... \" and select \"KDevelop 2 Project Files\" in the \"Filter:\". You can have and run KDevelop3 and KDevelop2 at the same time on the same computer without any problems. So migrating is a breeze. :) P.S. : The KDevelop team closed over 452 reported and confirmed bugs since the release of KDevelop2.1.3 The bad news is that KDevelop3 currently has 120 reported bugs :( '2003-07-15 14:18:19' 'rkoch@rkoch.org' Subject: Re: find callers of functions Unfortunatelly I am behind a huge firewall. Would you be so kind to send a tarball to ruediger.koch@db.com ? Thanks a lot -Rudiger --- Amilcar do Carmo Lucas <a.lucas@tu-bs.de> wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=61263 > a.lucas@tu-bs.de changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Version|unspecified |2.1.3 > > > > ------- Additional Comments From a.lucas@tu-bs.de 2003-07-15 12:01 > ------- > Sorry, KDevelop 2.x is no longer under development. > > You are strongly advised to update to the latest CVS version of KDevelop3, code name gideon, take a look at: > http://www.kdevelop.org/index.html?filename=branches_compiling.html > for all the details you need. > If you find a problem or need help please send a mail to the mailing list: > http://www.kdevelop.org/index.html?filename=mailinglist.html > or drop us a line at the channel #kdevelop on the server irc.kde.org using ksirc, for example. > Please use the CVS version and compile it yourself because that way you can easily patch it if a bug is found. > > KDevelop3 can open Develop2 projects. > To do so, goto the \"Project -> Open Project ... \" and select \"KDevelop 2 Project Files\" in the \"Filter:\". > You can have and run KDevelop3 and KDevelop2 at the same time on the same computer without any problems. > So migrating is a breeze. :) > > P.S. : The KDevelop team closed over 452 reported and confirmed bugs since the release of KDevelop2.1.3 > The bad news is that KDevelop3 currently has 120 reported bugs :( '2003-07-15 17:17:07' 'Amilcar do Carmo Lucas' ftp://ftp.kde.org/pub/kde/unstable/snapshots/kdevelop.tar.bz2 '2003-07-16 10:48:11' 'rkoch@rkoch.org' Subject: Re: find callers of functions Let me first say, I am really impressed with gideon. It shows a lot of potential! Excellent work so far. I am really looking forward to the stable releases. The specific feature I was looking for is still not present, although the grep works, as long as it is looking for pointers as foo->doit(); foo.doit() is not found. My coworkers did not all master regular expressions. For them, a \"find callers\" item that simply does what is requested without intimidating them with a dialog sporting an arcane regex would be close to ideal. That menu item should be in the class view - the context menu of a function. The regex (\\.|\\->|::)[\\t ]*\\<%s\\>[\\t ]*\\( is getting close. It finds the function definition itself and the \"\\fn ClassName::doit(), however - we may filter it out in a second pass. This would also find Bar::doit() even if Bar has nothing to do with Foo, but - nobody is perfect. -Rudiger --- Amilcar do Carmo Lucas <a.lucas@tu-bs.de> wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=61263 > > > > > ------- Additional Comments From a.lucas@tu-bs.de 2003-07-15 17:17 > ------- > ftp://ftp.kde.org/pub/kde/unstable/snapshots/kdevelop.tar.bz2 '2003-09-09 10:01:38' 'Alexey Arzamasov' I guess the feature you are talking about is like a 'Find Usage' feature as it works in IntelliJ IDEA (Java IDE), so, this is good. I just want to add here, a some behaviour one could add while implelemnting this feature. Along with having a 'Find Usage' feature wich produce a list of places in the project like the 'Grep' do, is would be very nice to have an 'Hightlight Usage' feature wich is just hightlight the usage of a function or a variable in the currect file only and do not produce any windows. Having binded this to some shortcut is very handy. Look how it works: - The user presses Alt+Shift+F7 (e.g.) - Gideon hightligh the usage of currenlty selected funciton/variable (or one which is under the cursor and not selected) - User got the response, make his/her mind clear about the usage - User press Esc and hightligh turned off. '2003-09-19 20:36:31' 'Amilcar do Carmo Lucas' This is comming. Stay tunned! '2003-10-02 14:48:47' 'Mike Whittaker' Call Tree/Graph Viewer Not only \"Find Usage\" - why can't C users have a \"Function Call Tree\" view - either organised by caller or by callee. This used to be a standard part of IDEs such as Borland, but has been substituted with a Class Viewer - I don't say 'replaced' since a Class Viewer is no replacement for a Call graph view ! Forgive me if this is in KDEv 3.0/Gideon ... '2007-12-03 17:57:50' 'Paul Fee' *** This bug has been confirmed by popular vote. *** '2007-12-03 18:02:59' 'Paul Fee' Doxygen includes similar information. It has a call graph but (unfortunately) lacks a called-by graph. It would also be nice if this feature was clever enough to understand C++ scoping rules, e.g. a call within foo::bar() to boo() could be a call to foo::boo() or boo() or a function within a namespace previously specified with \"using namespace\". Grep will not provide enough intelligence to find such matches. However it's not a bad start if use of a C++ AST is too complex. '2007-12-07 19:41:42' 'Andreas Pakulat' Just to get all these voters a bit excited: A basic experimental use-highlighter has been implemented in KDevelop4 the last days. AFAIK it currently highlights only usages of variables, but extending that shouldn't be much of a problem. '2008-06-29 15:52:06' 'Andreas Pakulat' comming in kdevelop4. '2009-01-31 21:55:57' 'Amilcar do Carmo Lucas' This is Fixed in KDevelop4 Take a look at \"code navigation\" blog on www.kdevelop.org for details '2009-03-28 11:35:10' 'mangus' version: svn (using Devel) OS: Linux Installed from: Compiled sources In amarok2-svn I like the the new contextview , but I found the new bottom bar for managing applets annoying , as it covers parts of other applets sometimes , like lyrics one , so that you miss a part of it. Could be handy to have it appear and desappear onmouseover. thanks '2009-03-28 14:53:55' 'Dan Meltzer' The real solution is to make it not cover applets, not make it appear/disappear on mouse over. '2009-03-29 14:34:53' 'Leo Franchi' i dont understand your point, dan... how do we make it not cover applets? '2009-03-29 16:32:22' 'Dan Meltzer' Thats your problem to solve :) The toolbar should be like the panel in kde, it gets it's own area to draw in (a strut in window manager terms). The applets should not consider the space the toolbar takes up to be theirs to play in, but rather end at the top of it. '2009-03-29 17:26:09' 'Leo Franchi' well if i move a window on my desktop down, the panel does cover it. so i still don't understand... '2009-03-29 18:19:23' 'Dan Meltzer' right, but new windows placed on the desktop do not get placed under the panel, and maximizing windows doesn't put them under the panel either. You need to explicitely place the window under the panel, and I considder it a bug that it's possible (but that's not what this debate is about).] The panel should not obfuscate applets by default. '2009-03-29 18:53:15' 'Mark Kretschmann' I fully agree with Dan here, and I also fully admit that I don't have the slightest clue on how to implement this technically :) But I really think that what he wrote makes a lot of sense, if feasible. '2009-03-29 19:39:03' 'mangus' Created an attachment (id=32462) [details] amarok-svn toolbar overlap '2009-03-29 19:39:39' 'mangus' Me and Dan are meaning this.. a screen is better then words sometimes :-) '2009-03-29 19:44:35' 'Leo Franchi' i know what it looks like, 've been staring at it all day. btw, that screenshot is outdated now :) i still don't see how else you guys plan to visualize it. do you just want a border for the applet area, so instead of hitting the panel directly, it ends at the border? i mean, applets *will* be logically under the location of the panel---all the applets that a user can have will not fit on the screen at the same time---so how else to show it? '2009-03-29 19:50:43' 'Dan Meltzer' The applet should end where the toolbar begins. Applets should not be larger than the viewable area, if there's an applet above it, then the lower applet should get a smaller sizehint, and resize if necessary when it's the active applet (and therefore the only one on the screen) Basically, no applet should continue on off the screen, it should end at the panel. '2009-03-29 19:58:27' 'Leo Franchi' i disagree :) what you are describing is a very different use-case of the CV in general, and distinctly different from what the original idea that was developed. in fact, i think there is another bug where we've already had this discussion (with mark), and this has come up on IRC. anyway, this is not something to be fixed, but rather a change that needs to be discussed with people like e.g. leinir. regardless of all of this, the problem of \"applets falling off the end of the screen\" should be mitigated when we are able to resize applets. '2009-03-29 20:48:48' 'Dan Meltzer' You can't tell me that the screenshot attached to this bug is intended. There is no way to see the final line or two in the lyrics applet. This is a major bug. '2009-03-30 17:30:19' 'Dan Leinir Turthra Jensen' The bug that is being shown here is the fact that you cannot yet resize your applets, and as such we also don't set default sizes sanely. You are reporting a bug on a non-completed feature ;) '2009-03-30 19:10:07' 'mangus' infact it was a wish! ;-) '2009-03-30 20:04:58' 'Dan Leinir Turthra Jensen' Of course :) Just thought i should point out that the feature is not yet completed - the polish that's gone into it مately could seem like an indication of feature completion, and as such it would seem the prudent course to inform you فhat that is not the case :) '2009-03-31 00:33:48' 'Dan Meltzer' I don't think that this should be dependent on being able to resize freely at all... Most of the time, the sizegrip for resizing ends up in the bottom right corner, and as such, would be inaccessable reguardless of whether it was free sizing or not. The bug isn't that the applet can't be made smaller, but that part of the applet is completely inaccesible. '2009-03-31 15:56:48' 'Kevin Funk' I fully agree with Dan aswell. I don't understand the confusion as it doesnt matter at all if an applet is resizable or not. To quote Dan: \"The applet should end where the toolbar begins. Applets should not be larger than the viewable area, if there's an applet above it, then the lower applet should get a smaller sizehint, and resize if necessary when it's the active applet (and therefore the only one on the screen)\" That's the expected behaviour and what is used in the playlist aswell. Track items dont overlap the lower toolbar, do they? '2009-05-17 17:22:44' 'Dan Meltzer' *** Bug 174221 has been marked as a duplicate of this bug. *** '2009-05-18 01:02:22' 'Leo Franchi' will be fixed in 2.1.1, done locally. '2009-06-02 10:34:10' 'mangus' I found it probably fixed in trunk :-) can Leo confirm that? we could close this.... '2009-06-02 10:45:41' 'Leo Franchi' yep, sorry forgot to close when i pushed. '2004-08-28 22:18:10' 'Janis Blechert' Version: 0.9.0 (using KDE 3.3.0, Gentoo) Compiler: gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6) OS: Linux (i686) release 2.6.8-gentoo-r3 Since Kopete is a multimessenger and has the idea of metacontacts etc I don't think it's neccessary to display on which network the contact is online (because it doesn't matter), this makes even more sense if you have people who have several different accounts and irc nicks and keeping track of all of them can quite clutter the contact list, so I would simply like an option to turn of the displaying of the tiny icq/irc/etc icons right (or wherever you choose them to be) of the display name, hope this will be done any time soon, thanks for kopete it's such a great app! '2004-09-29 19:46:43' 'Georges Goncalves' I'd like an option to do exactly the OPPOSITE ! :-) In fact, the contact list is organised as [KopeteStatusIcon][ContactName][ProtocolIcon]. Well, I'd like a way to tell Kopete to display only [ProtocolIcon][ContactName]. In fact, the best way would be to allow a CSS customisation of the contact list, just as we can have in message windows :-) '2004-09-29 21:07:53' 'Richard Smith' I am already considering adding that feature for the next version of Kopete; there are no technical or technological problems preventing it. However, there may not be time to implement it before KDE3.4. '2004-09-29 22:11:42' 'Jason Keirstead' On September 29, 2004 04:07 pm, Richard Smith wrote: > ------- I am already considering adding that feature for the next version of Kopete; there are no technical or technological problems preventing it. > However, there may not be time to implement it before KDE3.4. Richard, are you hinting that you are going to render the list view inside a KHTML widget? That would be hella cool, but also hella complicated. '2004-09-29 23:27:58' 'Richard Smith' On Wednesday 29 September 2004 9:13 pm, Jason Keirstead wrote: > Richard, are you hinting that you are going to render the list view inside a KHTML widget? It's an option I'm considering, for sure. But the current contact list code is quite flexible - flexible enough to allow me to throw together a drag-and-drop style editor for it, at least. This needs more discussion before anything gets coded. Richard '2007-11-14 14:44:00' 'Will Stephenson' Something to think about for 4.1 '2008-07-21 14:59:38' 'Ramon Antonio Parada' I think many people would be interested in showing this. Maybe an option could be added (if enought demand) to disable it. '2009-03-30 10:33:56' 'Roman Jarosz' Fixed in trunk (SVN commit 946606) will be in KDE 4.3, in trunk user can define contact list layout so you can hide the icons or change order. '2003-10-25 00:53:11' 'Martin Köbele' Version: (using KDE Devel) Installed from: Compiled sources identation itself works fine. But: let's see this example: hello1 hello2 hello3 If you go with the cursor to hello2 and press ctrl-i, hello2 is moved even further to the right. The right (and expected) behaviour is that hello should be moved to the left so it is right under hello1. (compare it with the behaviour of tab in xemacs) In my eyes, this really needs to be fixed. Thanks!!! Martin '2003-10-25 00:54:41' 'Martin Köbele' oh dear, the formatting is lost. Imagine, that hello2 is moved a bit to the right, like a \\t in front of it. Martin '2003-10-25 01:05:45' 'Jesse' Hmm, why would hello2 move left? Are you saying it should align itself to the 'closest' tab boundary? So if you had a tabspace of 8 characters and you had ........hello ...........hello2 Ctrl-I on hello2 should move it left because it's only 3 away from the left boundary but 5 away from the right one? For Kate, ctrl-I semantics have always been to unconditionally insert a 'positive' indent. Positive meaning to the right. This is a bug wrt other editors ... '2003-10-25 01:11:35' 'Martin Köbele' hi, hello2 should be moved to the left, because it is not aligned with the line above. Martin '2003-10-25 09:30:53' 'Martin Köbele' Martin Köbele 2003-10-25 09:30:53 ------- let me try it again: let's say we have the code something { ........hello1(); ...........hello2(); ........hello3(); } if you go now with the cursor in the line of hello2, hello2 should be moved to the left, because 1.) identation is about +8 spaces in a block, beginning from the opening parentheses (amount of spaces depends on your configuration of course). 2.) hello1 specifies where the block shall be aligned. Martin '2003-10-25 19:22:52' 'Jesse' Right, so you are looking for an 'Align' action. This is more of a 'wishlist' since Kate doesn't really have this (see below). It has unconditional indent left and right. If you want hello2 to move left go to Tools and hit 'Unindent' which will move it left to the tab stop. If you 'Indent' it will move to position 16, the next tab stop to the right. You can alternatively try 'Clean Indentation' and see if that aligns the misaligned blocks of code for you. It will even out the misaligned blocks of code most of the time if it can. '2004-01-02 01:18:24' 'Jesse' *** Bug 71479 has been marked as a duplicate of this bug. *** '2004-02-25 05:01:38' 'Jesse' *** Bug 75951 has been marked as a duplicate of this bug. *** '2004-06-02 05:37:41' 'Jesse' This is available in cvs. Currently it works only if you use the 'cstyle' auto-indenter. The default shortcut is CTRL + TAB (controlled tab) and will align the current line OR the block of text you select according to normal c/c++ conventions. See also bug 40656 for further information and a warning. '2004-06-02 12:23:11' 'jkyro@pp.htv.fi' How does this work with things inside parenthesis, like parameter lists and conditionals? I'd like to have it as in emacs: if ( foo == 1 && bar == 2 ) { doit(); } In this case the second condition should be aligned with the first one, not according to normal stuff. And parameter list handling like: int foo( int bar, char *baz, struct sizzle *gee ) { ... } In this case the closing parenthesis should be aligned with the opening one. '2004-06-03 06:58:47' 'Jesse' Yes, your first example works as expected. Your second example kinda works right now. Parameter lists are aligned just like you expect but it needs a reference character in the 'int foo (' line to judge what col to align to after that. Also, closing parenthesis are not aligned with the opening one. If this is really a problem for you, open up another wishlist item with appropriate examples. '2004-06-03 09:26:12' 'Martin Köbele' great, thanks a lot!! there is one little bug though: . . foo(); . . bar(); if your cursor is in the line between foo() and bar(), in the line where no tabs are made yet and you press now the shortcut for the new align, the cursor just won't move under foo(). but the rest of it works very nicely! Thanks guys! Maybe re-open this bug since I think the feature is incomplete, but I can open a new bugreport about this. Thanks Martin '2004-06-03 17:28:26' 'Jesse' With regards to the foo-bar problem, this was intentional. I didn't want to indent empty lines as that would leave quite a bit of useless leading spaces when selecting large regions and hitting Align -- it's also MUCH slower if I do not skip these lines when formatting an entire document. I guess I could make it so that's only the case when you're aligning a _block_ of text though -- I'll see what I can do. '2009-01-11 14:46:56' 'Kari Argillander' I cannot get this feature work. Is this working on kde4 beta2? '2006-01-14 13:51:03' 'bruno' It would be usefull to add a \"Swap\" button to quickly change the aspect ratio between portrait and landscape. This is needed when extracting a portrait from a landscape photo. '2006-05-21 19:31:19' 'weskaggs' Since there is no sign that this is going to happen for 2.4, I am bumping the target to Future. '2006-09-13 06:04:37' 'Sven Neumann' *** Bug 355694 has been marked as a duplicate of this bug. *** '2006-09-13 22:33:51' 'weskaggs ' I'm going to reset this to 2.4 because I expect to implement this very soon. '2006-12-14 01:54:14' 'Albert Cahalan' An easier and much faster user interface: swap between portrait and landscape based on mouse movement. You already have to move the mouse to make your selection. You'll likely do something that is approximately the right ratio. If that's closer to portrait, then portrait should get used, otherwise landscape should get used. Another way to explain this: When the user makes the selection, select landscape mode if the horizontal mouse movement is greater than the vertical mouse movement, otherwise select portrait mode. That's one less confusing button occupying screen space. That's one less button to press. You can work faster, with less hand/finger/wrist pain. '2006-12-14 07:01:52' 'Sven Neumann' Albert, you completely misunderstood this. The point is being able to flip the aspect ratio after you have created your rectangle selection. '2006-12-14 13:18:50' 'Simon Budig' Really? I found Alberts comment spot on. It basically would eliminate the need for this kind of button, since both x and 1/x would work equivalently in the GUI. I don't see much point in being able to flip the aspect *after* the creation of the rectangle. The placement of the resulting rectangle would need readjusting anyways (what is the fixed point of the rectangle while flipping?) and it sounds much more natural to me to be able to switch the orientation on-the-fly while creating the rectangle. '2006-12-14 13:44:00' 'bruno' I'm the reporter of the wish. Sven is right, I meant that it would be usefull to have the swap option after the creation of the rectangle selection. I do it \"by hand\" often in that case : I've a landscape photo that contains an interesting flower for example. I want to print a photo that have the same proportions as the original, but in a portrait format, more adapted to my flower. 1. I first \"take a shhot of the aspect ratio\" by selecting all the original landscape photo. 2. I freeze the aspect ratio (with the appropriate checkbox) 3. I shrink the rectangle to permit him to be rotated by 90° 4. I \"rotate\" him by taking my calculator, and calculating 1/[aspect ratio], and putting it by hand 5. I've now a perfect portrait zone wich I can adapt freely to my flower; and I'm happy :) I don't know if adding a toolButton just to do it is a problem, but I really think I'm not the only one to do that sort of cropping on a photo. Thanks for interest ! Bruno '2006-12-14 13:57:16' 'Jeffery Small' I agree that Albert's idea makes sense. Have gimp assume a landscape or portrait orientation automatically depending on whether the rectangular area swept out by the user is wider or higher. This might only be problematic when the aspect ratio was nearly, but not exactly square, but even here the user could control the proper aspect by exaggerating the motion in the larger of the two directions. If a swap button is maintained as in 2.3.12, then register the initial point used to sweep out the rectangular area and use that as the anchor rather than the upper-left corner as is now used. It is very likely that the first point selected by the user will be a desired point and this will not be the upper-left corner unless this happens to be where they started. As I stated elsewhere, it would also be great if the aspect ratio was automatically set to the initial aspect of the image being loaded. You might provide a \"lock\" button to force the current aspect ratio to be retained upon subsequent loading of images for those times when someone wants to crop a series of pictures to the same proportions. Maybe the current Fix button could be a toggle that switched between \"Lock\" (lock the aspect ratio - current behavior) \"Set\" (automatically set the aspect ratio for each new image and then locks it) \"Auto\"(the Set behavior combined with the behavior suggested by Albert) or \"None\". Having said this, I do appreciate having a toggle button at all. Thanks. '2006-12-14 19:30:49' 'Sven Neumann' Making this depend on the user's mouse action is not discoverable. There wouldn't be any way for the user to find out how to swap the aspect ratio. No way. It might make sense to determine the initial aspect ratio this way. But there still needs to be a button to swap it. Comment #7 is exactly the usage scenario for this. '2007-02-10 12:25:58' 'Sven Neumann' This is now implemented in trunk and seems to work reasonably well. Closing as FIXED. '2006-08-16 14:00:00' 'John Arthorne' community has voted for. \r\nExamples include double-click-drag to select multiple words, triple-click, extensible hyperlink support and spell checking. \r\nWe should also improve the current search/replace dialog. \r\n[Platform Text, Platform UI,SWT] '2006-08-17 02:48:57' 'Dani Megert' >We should also improve the current search/replace dialog. Those will be minimal improvements like being able to resize the dialog. We won't completely redesign the dialog e.g. to provide Firefox-like search unless it is contributed by a patch. '2006-09-02 19:25:44' 'Eugene Kuleshov' Here is few things to look at: -- Ctrl-Backspace don't work in all text editor widgets (try fields in search dialog or text fields in plugin.xml editor) -- support for seaching multiline text and alow to replace into multiline text -- improve usability of search dialog. Namely, replace direction radio buttons with additional buttons like \"Find previous\", \"Replace previous\". This would make getting back to accidentally skipped search match much easier. '2006-09-04 02:33:08' 'Dani Megert' >-- Ctrl-Backspace don't work in all text editor widgets (try fields in search dialog or text fields in plugin.xml editor) Please file separate bug reports, e.g. we do not control the PDE editor - thanks. '2006-09-04 10:05:04' 'Dani Megert' >-- Ctrl-Backspace don't work in all text editor widgets (try fields in search The problem here is that JDT UI started to map the text editor's editing commands onto the text, combo and other widgets using TextFieldNavigationHandler. It would be possible push parts of TextFieldNavigationHandler down to Platform Text to provide this for dialogs around the editor but I think this is a more general issue since users then also expect the navigation commands to work in wizards, Ctrl+H search pages etc. But this can't be adopted by JFace because they don't depend on the text editor plug-ins. To solve this, JFace will have to adopt/define editing commands that can be used along with widgets and would have to provide the navigation handler(s). Can you file a bug report against Platform UI and describe the problematic. Please add myself to the cc-list. Thanks. '2006-09-06 10:36:19' 'Dejan Glozic' (In reply to comment #0) > extensible hyperlink support I would prefer if extensive hyperlink support is much lower (ideally at the StyledText widget but if not, at the JFace level). UI Forms would like to port from FormText to StyledText. StyledText has added many key features in 3.2 time frame with hyperlink support being the last one we need in order to port. '2006-09-06 11:08:41' 'Dani Megert' Dejan, you're not allone ;-) Feel free to add your comments to bug 156219. The one in text land is bug 88293. '2006-09-27 10:45:42' 'Andreas Goetz' I'd like to throw in bug 145959 (forgive me if this doesn't apply to text editors): On Windows, multi-line text boxes as used e.g. in the Run->Arguments dialog should support Return key in two ways: [Return]: add CR/LF to current text box [Ctrl-Return]: send Return key to parent dialog (similiar to executing the default action). '2006-09-27 11:19:22' 'Dani Megert' >I'd like to throw in bug 145959 (forgive me if this doesn't apply to text editors): Nothing to forgive just to ignore ;-) This plan item covers Platform Text. You have to place your feature with Platform SWT. '2007-03-27 05:04:46' 'Dani Megert' Completed as of I20070327-0800. '2007-04-13 23:38:40' 'john Hutcheson' Some were hoping to drag source code is 3.2, perhaps they'll get it 3.3. And of course, it should be optional for those who would have a man run ahead of a horseless carriage with a red flag. '2004-03-21 16:23:20' 'Dan Mellem' User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b)Gecko/20040316 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)Gecko/20040206 Firefox/0.8 There needs to be a way to open sidebar resources, such as the history and bookmarks, in their own window. It's more convenient to have a single history window that doesn't take up screen real estate than having to open the history in whichever window I'm currently browsing. I like the CTRL-B and CTRL-H features of Mozilla and would like that carried over. I know bug 178199 discusses CTRL-B (WONTFIX but perhaps CTRL-SHIFT-B) in particular but I'm talking about depending on the side bar at all. I really hate sidebars and would want to be able to disable them in place of these windows before I would migrate to Firefox. Since the roadmap is now to focus on the standalone apps with \"a conservative,sustaining engineering fashion\" type of support for Mozilla/SeaMonkey, I think a \"SeaMonkey Parity\" of some form should be established. Thanks. Reproducible: Always Steps to Reproduce: '2004-03-22 17:02:52' 'Jesse Ruderman' A bookmark manager window already exists, and bug 178199 covers giving it a better keyboard shortcut than Alt,B,M. I don't see a bug for adding a history window. '2004-03-26 05:31:57' 'miahz' how about something like about:history? similar to about:config - just a full page tree with a search/filter field at the top. you wouldn't really need a menu or toolbar buttons like with the bookmarks manager. but like the bm and unlike the sidebar, it would have all the sortable columns: name, url, last visited, first visited, number of visits, etc. it would be the \"power-user\" supplement to the simple history sidebar. sure, the sidebar needs a few things fixed like searching urls, but other than that, i think it's fine for most uses - exactly what sidebars are for - a quick way to access something without leaving/obscuring the current page. and an about:history page would nicely fill in the gap left on the advanced end. a whole new history window is probably overkill, and a page could just as easily be opened in its own window or in a tab. while i'm brainstorming, you could probably even add a search shortcut ability so you could type something like about:history?extensions to open the history page and filter pages with \"extensions.\" compare: chrome://browser/content/history/history-panel.xul chrome://browser/content/bookmarks/bookmarksPanel.xul chrome://browser/content/bookmarks/bookmarksManager.xul about:config reporter, not sure if you're asking for a whole new history window, or just the ability to open the sidebar history in its own window. if the latter is the case, then just open the above chrome url in a new window. the component and other fields probably need to be updated. '2004-03-26 11:25:28' 'Dan Mellem' I'm really looking for two things: 1. A separate window so I can keep going back to the same window and open multiple windows from this window. chrome://browser/content/history/history-panel.xul would meet this need. 2. Being able to see and sort the history. Seamonkey offers tabs for Title, Location, Last Visited, First Visited, Hostname, Referrer, and Visit Count. Not all of this is needed but at least the first four are helpful. Plus, I'd like to be able to open this easily, such as with /-\\H. '2004-11-27 13:46:29' 'Jeroen' Please add the Mozilla history window in Firefox! I think this is just one of the things that's missing in inferior browsers like Microsoft Internet Explorer. The Mozilla history window is just perfect! '2005-09-17 22:40:13' 'Wayne Mery' (In reply to comment #3) > I'm really looking for two things: > > 1. A separate window so I can keep going back to the same window and open multiple windows from this window. > chrome://browser/content/history/history-panel.xul would meet this need. > > 2. Being able to see and sort the history. Seamonkey offers tabs for Title, Location, Last Visited, First Visited, Hostname, Referrer, and Visit Count. > Not all of this is needed but at least the first four are helpful. Firefox sure doesn't seem like a total product with a decent history. EHM, Enhanced History Manager, is an extension that does it nicely. http://forums.mozillazine.org/viewtopic.php?p=1749502#1749502 '2006-02-27 13:45:11' 'seren' I agree that the firefox history is limited at best. I'm amazed that there is no way of knowing what the url or date of a history entry is. Mozilla history was excellent since you could re-trace your browsing using the timestamp and find collections of pages you'd visited. History (in life and browsing) is more useful when there is a context. Shouldn't there be an option to see when and what order a page was visited? '2008-10-23 09:05:25' 'Jason A. Donenfeld' Version: svn (using Devel) Compiler: gcc 4.3.2 gentoo OS: Linux Installed from: Compiled sources If you navigate, using the file browser, to a song in the collection and select \"move to collection\", and ensure that the new file name is the same as the old file name, the song is renamed to itself (not renamed), then deleted. The fix for this it to make sure that songs moved into the collection are not removed during the \"move to collection\" operation. A patch is below. '2008-10-23 09:08:55' 'Jason A. Donenfeld' Created an attachment (id=28078) [details] bug fix Patch by Jason A. Donenfeld <Jason@zx2c4.com> This patch fixes the bug by checking if the song is in a collection before removing it after the move operation. A potential problem is that it may fail to remove it from a collection when moving a track from one collection to another. '2008-10-23 10:29:48' 'Seb Ruiz' Just for the record, this patch is incorrect and shouldn't be applied. '2008-10-23 10:58:33' 'Jason A. Donenfeld' Created an attachment (id=28083) [details] semi correct patch Patch by Jason A. Donenfeld <Jason@zx2c4.com> This patch fixes the problems of the above patch and gets to the heart of the issue: \"KIO::file_copy\"ing with the src and dest the same will erase the file. This patch checks to see if the KURLs are identical before attempting to copy. This is the same logic as used elsewhere in the modified file, so it was chosen to keep convention. However, it still suffers from a problem: if the KURLs point at the same location but have different string paths, for example /home/user/music/artist/song.mp3 and /home/user/music/artist//song.mp3, the test will fail. Therefore, this patch needs only a fix for this comparison problem, and then it should be ready to be applied. '2008-10-23 11:50:22' 'Mark Kretschmann' Jason, you can use KUrl::cleanPath() to fix this. See here: http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKUrl.html#05eaea3296e3778f04014bd943ac894a '2008-10-23 12:15:29' 'Jason A. Donenfeld' Created an attachment (id=28087) [details] fixed final flaw Mark - thanks for the suggestion. This patch solves the above patch's problems. Patch by Jason A. Donenfeld <Jason@zx2c4.com> \"KIO::file_copy\"ing with the src and dest the same will erase the file, so this patch checks to see if the KUrls are identical, after cleaning the urls, before attempting to copy. '2008-10-23 12:17:58' 'Seb Ruiz' Since Max is the author who wrote the Collection code (including copying/moving), I'm going to wait for his approval to this patch before committing, lest we make an oversight. '2008-10-23 12:19:55' 'A. Donenfeld' Sebr - sounds good. I can commit it myself, hopefully, because I should have svn commit access soon enough. (sysadmins are usually pretty fast, no?) '2008-10-23 13:20:07' 'Maximilian Kossick' I can't test this at the moment, but I've got a couple of comments after reading the bug report and the patch: I didn't look up the api documentation, but using KIO::file_copy with the same source and destination url sounds like a bug in kdelibs. And I don't think that that is actually happening. Because you are moving from the filebrowser, SqlCollectionLocation doesn't notice that it's dealing with a file already in the collection, and therefore doesn't use the special code that stops it from removing files from the source collection. I am a bit surprised that the patch even works (does it?). CollectionLocation should be removing the source files (because you are *moving* files) after the copy operation, which is probably when your files actually are deleted. '2008-10-23 13:34:41' 'Jason A. Donenfeld' Max, This was my initial thought too... that really the problem was that it was removing the source after moving. But then I fully mapped the flow, and I saw that that section never even gets called if sourceLocation = 0 (if it's coming from a file and not another collection). The logic for that part works fine, with m_tracksRemovedByDestination being correctly populated and processed. The thing is that removal code is never called when sourceLocation = 0. Generally copying or moving a file into itself will delete the file; I've seen this behavior in other languages and commands, and kio doesn't appear to be an exception. The patch does in fact work. Something still may be suspicious, though. '2008-10-23 14:02:40' 'Maximilian Kossick' Jason, are you sure that FileCollectionLocation::removeTrack does not get called? I just checked the code which starts the move operation in the filebrowser, and it creates a FileColelctionLocation. Therefore sourceLocation will always be 0, the file will be copied (and deleting a file whehn copying or moving it onto itself *is* a bug), and *CollectionLocation* will call removeTrack on the source location as part of its workflow. '2008-10-23 14:33:30' 'Jason A. Donenfeld' Aaaaa hah! With job never being assigned, slotJobFinished is never called, and if slotJobFinished is never called, slotCopyOperationFinished is never called, and if slotCopyOperationFinished is never called, slotFinishCopy is never called, and if slotFinishCopy is never called, removeSourceTracks is never called, and if removeSourceTracks is never called, remove is never called, and if remove is never called, QFile::remove is never called. This shouldn't happen though. While this works, you're right: there is something screwy going on. Why doesn't slotCopyOperationFinished get called independently of slotJobFinished? Or is it supposed to work this way? '2008-10-23 14:39:44' 'Maximilian Kossick' no, slotCopyOperationFinished should be called if we don't actually have to copy any tracks. That's a bug. '2008-10-23 14:54:30' 'Jason A. Donenfeld' Ok. I see how it all works now. New patch coming soon. '2008-10-23 15:29:10' 'Jason A. Donenfeld' Created an attachment (id=28094) [details] adds movedByDestination to CollectionLocation ignoredDestinations was removed, as this was no longer pertinent, since it was only used in the flow from a job event. movedByDestination was added to collectionLocation, since this is something all collectionlocations will potentially need to account for. slotCopyOperationFinished is now called if no job is created. Since m_removeSources is now protected and part of CollectionLocation, collections that cannot move but only copy will just set m_removeSources to false in their constructor. If you like this, I'm able to commit myself now. But I'm guessing you'll have suggestions. '2008-10-24 01:38:35' 'Jason A. Donenfeld' I should probably make the map private and just add another protected accessor function. If we go this route, I should also make the protected accessor functions virtual and add proper comment documentation. '2008-10-28 09:58:26' 'Jason A. Donenfeld' SVN commit 876841 by jdonenfeld: This prevents deleting a song when moving it or organizing it into its original path name by making sure the source and destination are different before [re]moving. This functionality is also potentially extended to all CollectionLocations, as now the base class has public functions to keep track of such things. This also cleans up the logic and flow quite a bit. BUG: 173341 M +29 -2 CollectionLocation.cpp M +18 -3 CollectionLocation.h M +27 -44 sqlcollection/SqlCollectionLocation.cpp M +1 -6 sqlcollection/SqlCollectionLocation.h M +5 -5 support/FileCollectionLocation.cpp M +0 -5 support/FileCollectionLocation.h WebSVN link: http://websvn.kde.org/?view=rev&revision=876841 '2008-01-16 16:31:06' 'Pavel Volkovitskiy' Version: (using Devel) Installed from: Compiled sources OS: Linux from some time ago ctrl+c stops work i have 2.1 konsole (kde 4.0.80+r762060 from trunk) reproduce: sleep 10 and press ctrl+c so now i use ctrl+z; kill %1; fg '2008-01-17 19:55:37' 'Urs Wolfer' Same problem here. Another thing which is IMHO releated: the konsole \"window cursor\" does not get anymore the focus (the cursor gets not filled white). This issues has appeared some days ago.. '2008-01-17 20:55:06' 'Hiếu Hoàng' Some info: when I use completion, C-c works (i.e. type \"pTABTAB\", while bash is tallying the possible completions, C-c stops the process and returns the prompt). This bug is possibly not in konsole, because yesterday I can't use C-[S-]v to paste in any app (including konsole), or C-l to clear screen (in konsole, gajim and pidgin). Grepping ~/.xssession-errors only yields one \"error\" in the search krunner runner. '2008-01-18 04:49:53' 'Thomas Georgiou' I get this with new konsole too, it works with some progs like strace, but not with others like ruby (which works fine in a vt). '2008-01-20 21:33:02' 'Urs Wolfer' This issue makes working with Konole really hard.. you always need to kill jobs from another Konsole... There are a lot of people asking about this issue on IRC. '2008-01-21 02:49:51' 'Robert Knight' I cannot reproduce here. > I get this with new konsole too, it works with some progs like strace, but not with others like ruby (which works fine in a vt). That is bizarre. I cannot think why the behavior might depend on what is running on the terminal. > There are a lot of people asking about this issue on IRC. Are they running Konsole from the KDE 4.0 branch or trunk? '2008-01-21 02:51:48' 'Robert Knight' > Are they running Konsole from the KDE 4.0 branch or trunk? You could winding kdebase/apps/konsole back a few revisions to see if the problem disappears. If you get as far as the KDE 4.0.0 tagging then it is likely somewhere else. '2008-01-21 14:06:51' 'Dmitry Suzdalev' Running trunk. Noticing this for some days. Working around that by doing \"Ctrl-Z and kill %1\"... '2008-01-21 20:46:24' 'Robert Knight' *** Bug 156320 has been marked as a duplicate of this bug. *** '2008-01-22 12:49:24' 'Robert Knight' > Running trunk. Noticing this for some days. As I cannot reproduce, I need to know which revision introduced the bug. You can use svn up -r <revision> to change kdebase/apps/konsole/src to an earlier revision. '2008-01-22 19:58:30' 'Paolo Capriotti' I can confirm this problem. The first revision where it happens is 760614: http://websvn.kde.org/?view=rev&revision=760614 '2008-01-23 12:37:17' 'Christian Muehlhaeuser' i'm running trunk. i can ctrl+c svn for example or a compile job. but i can't ctrl+c dselect (or btdownloadcurses or ...) '2008-01-23 17:20:11' 'Pavel Volkovitskiy' after i switch to konsole window, cursor doesn't filled and ctrl+c doesn't works, but if i type something then this passes to konsole _and_ cursor became fillled after that i'm able to use ctrl+c ie, switch to konsole press <space> (to get cursor filled) press ctrl+c (will work now) '2008-01-23 18:03:05' 'Pavel Volkovitskiy' this doesn't always work, cursor became filled, but ctrl+c doesn't work ctrl+c works in bash or read prompt (even with non-filled cursor) '2008-01-26 00:12:55' 'Dmitry Suzdalev' Robert, I can confirm what Paolo said: it happens first in 760614 revision (porting to KProcess). I also noticed this warning in Session.cpp's Session::sendSignal() function: #warning \"TODO: Send the right signal here, QProcess::kill() always sends SIGKILL\" I blindly tried to replace _shellProcess->kill() with _shellProcess->terminate(), but that did not help, so I gave up :) Maybe this even not that piece of code that causes the problem (although seems quite related). Maybe you'll have some further ideas. And I wasn't able to reproduce this bug on my machine at work, although both home and work machines run Debian/testing (but have different hardware). I'm puzzled what can cause this :) But while it's reproducable here, at home, I can test your ideas if any. '2008-01-26 00:25:10' 'Robert Knight' > I also noticed this warning in Session.cpp's Session::sendSignal() function: That is only called at the end of the terminal session to kill the main shell process. Otherwise Konsole doesn't touch any processes directly - it just sends the key presses you enter to the terminal. > although both home and work machines run Debian/testing In other words, they have the same versions of all common software? > (but have different hardware) Do they use the same type of CPU? I don't suppose it could be a 32bit / 64bit difference? '2008-01-26 00:27:58' 'Dmitry Suzdalev' Ah, no, seems unrelated :) How about this: void Pty::lockPty(bool lock) { #warning \"TODO: Support for locking the Pty\" //if (lock) //suspend(); //else //resume(); } Not sure if this is it too... '2008-01-26 00:30:22' 'Dmitry Suzdalev' > In other words, they have the same versions of all common software? Well, currently not, because I forgot that I updated home machine to debian/sid, but I recall that I was seeing this bug before I upgraded. Mmmm... not 100% sure though. 90% ;) > Do they use the same type of CPU? > I don't suppose it could be a 32bit / 64bit difference? Yep. Both use intel core duo '2008-01-26 01:00:58' 'Robert Knight' > Not sure if this is it too... No, that is called when Ctrl+S or Ctrl+Q is pressed. Can you try changing the interrupt key sequence to something else and see if it makes any difference. For example, change the interrupt key to Ctrl+Y stty intr /-\\Y Then try strace, sleep, make etc. but use Ctrl+Y instead of Ctrl+C to kill them. '2008-01-26 01:02:40' 'Dmitry Suzdalev' Chatting with ossi bringed up another very interesting usecase: Fact: ctrl-c doesn't work in konsole Next step: launch xterm and launch strace -ttt -o konsole.trace konsole --nofork Now in that started konsole app, 'make' breaks just ok! Wonders :) strace fixes things :) '2008-01-26 01:06:05' 'Dmitry Suzdalev' After changing /-\\C to be /-\\Y situation is the same for /-\\Y as it was for /-\\C: e.g. /-\\Y breaks 'strace', but not 'make' '2008-01-26 01:20:17' 'Robert Knight' > strace fixes things :) You're doing two things there though, running Konsole with strace and also with the --nofork argument. To be sure which was making a difference, you'd need to: 1. Run \"konsole --nofork\" (without strace) and see if the problem is still there. 2. Start Konsole normally (with no arguments), then attach to it with strace (using strace -ttt -p <pid of konsole>) and see if the problem is still there. '2008-01-26 02:07:56' 'Paolo Capriotti' The problem disappears for me with both 1 and 2, while changing the interrupt sequence has no effect just like Dmitry reported. Any idea where to look in the code, where to set breakpoints, etc...? '2008-02-06 13:34:24' 'Robert Knight' Fixed by SVN commit #771570. \"Fix Ctrl+C not killing applications on some users' systems. Reset all signal handlers to the default (SIG_DFL) in the child process after forking\" '2008-06-20 19:01:17' 'Yuriy Kozlov' Version: (using Devel) Installed from: Compiled sources OS: Linux Using nightly builds from project Neon, kdebase version 20080617+svn821478-0neon1 There seem to be some problems with the zoom out view. It doesn't layout the activities properly. Steps to reproduce: 1. Zoom out. 2. Add Activity. Now only the newly added activity is shown, in the top left corner of the screen. 3. Zoom in. 4. Zoom out. Now both the activities are shown, but not in the order they were added, and there is some whitespace around them. If another activity is added, this happens again, and have to zoom in and out twice to get all 3 activities to show. '2008-06-29 14:40:36' 'Diederik van der Boor' Same here at openSUSE, KDE 4.1 beta 2. '2008-06-29 14:47:57' 'Diederik van der Boor' I'm using NVidia binary drivers btw, have an NVidia Geforce 6600 GT. '2008-06-29 15:14:59' 'Diederik van der Boor' Just found out that the \"offset\" of the activity overview changes when you double click on the second activity. The same probably happens too when adding an activity. At this point, it's not possible anymore to use drag&drop to move to the first activity. Only zooming out, selecting the first, and zooming in fixes it. '2008-06-30 20:50:50' 'Chani' yeah, that regression crept in a while ago, and it's been bugging me a lot. we've actually got multiple bugs in this report, it'd be nice to separate them out (but I have to leave in a minute). 1) adding/switching activity makes the view jump suddenly to another place (it's trying to make sure the activity is visible, and being stupid about it) 2) dragging the view around to see other activities no longer works (regression! it worked before woc) '2008-06-30 21:22:58' 'Yuriy Kozlov' Actually, dragging around the view does work here *except right after adding an activity*. I just didn't know about that functionality when I filed this report. Adding an activity makes the view jump to another place, and also the placement of the new activity seems arbitrary. '2008-07-06 21:35:15' 'Thomas Georgiou' Bug = Add activity focuses view on the new activity until zoom level changes '2008-07-09 05:42:21' 'Chani' well then, let's make the title a bit clearer '2008-07-24 04:11:47' 'Luciano Leveroni' I think add activity option (and zoom out) should be removed in the 4.1 final. This bug is quite big, plus there's no clear way to delete an activity. Also,performance when zoomed out is slow as hell. I didn't report this issues because some of them are already reported and I thought others are pretty obvious. Don't get me wrong, it's a great idea, but it's current status makes it confusing, useless and buggy :S '2008-07-25 19:11:00' 'Chani' performace is fine for me. are you using nvidia? there are already people making use of multiple activities, we're not going to take that away from them. it'd be really really nice if this bug could be fixed somehow, though. '2008-07-25 19:13:41' 'Aaron J. Seigo' > This bug is quite big so huge it crashes your machine, loses dat, etc, right? this is a molehill, stop making it into a mountain. > but it's current status makes it confusing, useless and buggy so don't use it. we have gotten many reports of people who DO like it and are using it for day to day work. i suppose your desire to see this set of problems hidden overrides their productivity? and if we'd taken this approach in 4.0 we'd be even further behind. '2008-07-28 00:39:33' 'Chani' SVN commit 838477 by chani: when a new activity is added, don't move more than necessary to show it this seems to fix dragging the view around too :) BUG: 164545 please backport. M +7 -1 view.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=838477 '2008-11-07 13:43:53' 'Evert Vorster' Version: (using KDE 4.1.2) Installed from: Compiled From Sources Amarok version 1.94 When moving a large amount of files to my collection, amarok2 opens a file dialog for every single file that it moves. To reproduce: Make a directory where you would like your music collection to be stored. Go in to amarok2 and set it up so that the new collection area is included. Then, right-click on local collection, select organise and select the new destination for the files. Even my Core 2 Duo with 2 GB of RAM could not handle 16,000 file dialogs, and crashed my whole system hard, requiring a reboot. Can we please either: 1) move the files sequentially, or 2) not display a file dialog? '2008-11-08 08:51:36' 'Seb Ruiz' Sorry, I can't reproduce this. I just tried, and there is information shown in the progress bar and nowhere else. I'm copying tracks to my local sql collection. I assume you are doing the same? '2008-11-08 09:30:31' 'Evert Vorster' Are you using Amarok to move the files? It still opens a file dialog for every file that it is \"organising\" I just checked again. I have the following options ticked on in the Organise files option. Use cover art for folder icons Ignore \"the\" in artist names Group by file type Replace spaces with underscores restrict to ASCII VFAT safe filenames Overwrite destination It might be that one of those options trigger this, or the combination. Weird. Once I started messing around with what is ticked, the problem went away. Now I am also unable to reproduce it. '2008-11-08 12:40:38' 'Evert Vorster' I have been able to reliably reproduce the bug. Use the files tab of amarok, then click on the directory that you want to move the files from, select move to collection. Select the following: Use cover art for folder icons Ignore \"the\" in artist names Group by file type Replace spaces with underscores restrict to ASCII VFAT safe filenames Overwrite destination It makes lots of file transfer windows for me, every time. -Evert- '2008-11-08 13:05:42' 'Seb Ruiz' I still can't reproduce this. Are you using copying using Amarok's filebrowser, or are you organising the collection browser? How did you install amarok (compiled, packages etc) and which platform are you using '2008-11-08 14:05:34' 'Evert Vorster' I am using Amarok's file browser. I think so, anyways. I click on the files tab. I have noticed that I only get the lots of file moving dialogs if I have all of those options ticked. Right now I am moving my files in to my collection with Overwrite destination unticked and I do not get the file dialogs then. I downloaded the source of amarok 1.94, and compiled it with gcc 4.2.3 I am using Sorcerer Linux, so all software on my system is hand-optimized and locally compiled. -Evert- '2008-11-08 14:12:05' 'Seb Ruiz' SVN commit 881542 by seb: Fix boolean logic which caused the progress info to be shown when overwriting tracks during a collection copy. BUG: 174533 M +2 -0 ChangeLog M +1 -1 src/collection/sqlcollection/SqlCollectionLocation.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=881542