|
Marcel,
Another bug : Press F5 : nothing happens. Album/refresh album : nothing happens. Gilles 2009/5/16 Marcel Wiesweg <[hidden email]>: > Hi, > > as of today the main icon view has been replaced with the new implementation > that has been under development for quite some time. > I have taken care to go through the old code and port every single feature, > but there is a lot of new code, so expect bugs and regressions. > If you are running from current svn and find such a bug until beta1, please > report it here shortly by mail, no need to flood b.k.o. I have not yet > tested the majority of features, but will do in the next days. > > Issues: > - Speed. (Talking about the 25000 pictures in the view situation). The idea > is to make things faster. May things have become slower? They may. I have > already eliminated performance issues with KCategorizedView. More to come. > It seems that the view is the limiting factor and the model is well > optimized. > - The rate-on-hover feature is waiting to be ported > - When new images are added in the background, currently the whole album is > reloaded - incremental update is a missing feature. > > Marcel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
I can confirm, seems to be some race-condition.
If you switch to another album, no image is actually selected. Look at the edit action in the toolbar for example, it is disabled. When you just rightclick on an item, it becomes selected (edit action in toolbar is active now), but somehow the context menu has already been created. Right-clicking the item again "fixes" the menu. The ContextMenuHelper normally removed disabled actions, to avoid an even bigger contextmenu. This is why some actions are not displayed. The actions are enabled in DigikamApp::slotImageSelected(), but the slot seems to be called slightly after the contextmenu is created. I guess we had this problem also before the ModelView port, but since I always click first on an item, I've never seen it. Andi On Sunday 17 May 2009 12:20:51 Gilles Caulier wrote: > With icon view pop-up menu, click right and look that menu is a > reduced version where Edit action do not appears. > > Close pop-up menu with ESC and re-open it : now it's the full version... > > Gilles > > 2009/5/17 Matthias Welwarsky <[hidden email]>: > > On Saturday 16 May 2009 18:00:23 Marcel Wiesweg wrote: > >> Hi, > >> > >> as of today the main icon view has been replaced with the new > >> implementation that has been under development for quite some time. > >> I have taken care to go through the old code and port every single > >> feature, but there is a lot of new code, so expect bugs and regressions. > >> If you are running from current svn and find such a bug until beta1, > >> please report it here shortly by mail, no need to flood b.k.o. I have > >> not yet tested the majority of features, but will do in the next days. > >> > >> Issues: > >> - Speed. (Talking about the 25000 pictures in the view situation). The > >> idea is to make things faster. May things have become slower? They may. > >> I have already eliminated performance issues with KCategorizedView. More > >> to come. It seems that the view is the limiting factor and the model is > >> well optimized. - The rate-on-hover feature is waiting to be ported > >> - When new images are added in the background, currently the whole album > >> is reloaded - incremental update is a missing feature. > >> > >> Marcel > > > > Some problems here navigating the view with Arrow buttons: If you select > > images with Shift plus Arrow buttons, you cannot cross the end of a row > > with left/right arrows. Up/Down arrows seem to work. > > > > Deleted images sometimes don't disappear from the view. > > > > Metadata update when navigating pictures is slower than before and seems > > to block the navigation. Is this now handled synchronously? > > > > Lots of flickering when deleting images (full repaints, view is erased > > and then completely redrawn). > > _______________________________________________ > > Digikam-devel mailing list > > [hidden email] > > https://mail.kde.org/mailman/listinfo/digikam-devel > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
If I click on the edit button in the toolbar, it sometimes works, mostly not.
Using the context menu always works. Strange. It looks like something is blocking the global action. Andi On Monday 18 May 2009 10:06:42 Gilles Caulier wrote: > Marcel, > > Another bug : > > Press F5 : nothing happens. > Album/refresh album : nothing happens. > > Gilles > > 2009/5/16 Marcel Wiesweg <[hidden email]>: > > Hi, > > > > as of today the main icon view has been replaced with the new > > implementation that has been under development for quite some time. > > I have taken care to go through the old code and port every single > > feature, but there is a lot of new code, so expect bugs and regressions. > > If you are running from current svn and find such a bug until beta1, > > please report it here shortly by mail, no need to flood b.k.o. I have not > > yet tested the majority of features, but will do in the next days. > > > > Issues: > > - Speed. (Talking about the 25000 pictures in the view situation). The > > idea is to make things faster. May things have become slower? They may. I > > have already eliminated performance issues with KCategorizedView. More to > > come. It seems that the view is the limiting factor and the model is well > > optimized. > > - The rate-on-hover feature is waiting to be ported > > - When new images are added in the background, currently the whole album > > is reloaded - incremental update is a missing feature. > > > > Marcel > > _______________________________________________ > > Digikam-devel mailing list > > [hidden email] > > https://mail.kde.org/mailman/listinfo/digikam-devel > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
Error messages from console always help (:=)))
Object::connect: No such signal Digikam::DigikamImageView::currentChanged() in /home/gilles/Documents/data/devel/SVN/trunk/graphics/digikam/digikam/digikamview.cpp:370 Gilles 2009/5/16 Marcel Wiesweg <[hidden email]>: > Hi, > > as of today the main icon view has been replaced with the new implementation > that has been under development for quite some time. > I have taken care to go through the old code and port every single feature, > but there is a lot of new code, so expect bugs and regressions. > If you are running from current svn and find such a bug until beta1, please > report it here shortly by mail, no need to flood b.k.o. I have not yet > tested the majority of features, but will do in the next days. > > Issues: > - Speed. (Talking about the 25000 pictures in the view situation). The idea > is to make things faster. May things have become slower? They may. I have > already eliminated performance issues with KCategorizedView. More to come. > It seems that the view is the limiting factor and the model is well > optimized. > - The rate-on-hover feature is waiting to be ported > - When new images are added in the background, currently the whole album is > reloaded - incremental update is a missing feature. > > Marcel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
Marcel,
It's always reproducible when digikamrc file is deleted. Look effect : http://farm3.static.flickr.com/2356/3544954645_bd9fd7e114_o.png After to change icon size, problem disappears... If you don't change icon size and restart digiKam, problem still here... Gilles 2009/5/17 Gilles Caulier <[hidden email]>: > A sode effect under windows only : > > - Starting digiKam. icon view show dates rating, tags and comments > under icons. thumbs size is 96. > - There is null space between icons. > - I change thumb sizes to 140. > - Space between icons appears as under Linux. > > Sound like an init race condition somewhere. > > Gilles > > 2009/5/17 Gilles Caulier <[hidden email]>: >> Marcel, >> >> All compile fine now. Great... >> >> Gilles >> >> 2009/5/16 Gilles Caulier <[hidden email]>: >>> Compilation is broken under Vista using MinGW (not yet tested with XP, >>> but it will be a similar pb): >>> >>> [ 27%] Building CXX object >>> digikam/digikam/CMakeFiles/digikam.dir/kcategorizedview.obj >>> C:\temp\devel\graphics\digikam\digikam\kcategorizedview.cpp:1510: >>> warning: non-inline function 'virtual void KCategorizedView::r >>> owsInsertedArtifficial(const QModelIndex&, int, int)' is defined after >>> prior declaration as dllimport: attribute ignored >>> C:\temp\devel\graphics\digikam\digikam\kcategorizedview.cpp:1610: >>> warning: non-inline function 'virtual void KCategorizedView::u >>> pdateGeometries()' is defined after prior declaration as dllimport: >>> attribute ignored >>> In file included from >>> C:\temp\devel\graphics\digikam\digikam\kcategorizedview.cpp:1689: >>> C:\temp\devel\graphics\digikam\digikam\kcategorizedview.moc:55: error: >>> definition of static data member 'KCategorizedView::stati >>> cMetaObject' of dllimport'd class >>> C:\temp\devel\graphics\digikam\digikam\kcategorizedview.moc:55: >>> warning: 'KCategorizedView::staticMetaObject' defined locally af >>> ter being referenced with dllimport linkage >>> C:\temp\devel\graphics\digikam\digikam\kcategorizedview.cpp: In >>> destructor `virtual KCategorizedView::~KCategorizedView()': >>> C:\temp\devel\graphics\digikam\digikam\kcategorizedview.cpp:543: >>> warning: non-inline function 'virtual KCategorizedView::~KCateg >>> orizedView()' is defined after prior declaration as dllimport: attribute ignored >>> make[2]: *** [digikam/digikam/CMakeFiles/digikam.dir/kcategorizedview.obj] >>> Error 1 >>> make[1]: *** [digikam/digikam/CMakeFiles/digikam.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> Gilles >>> >>> 2009/5/16 Marcel Wiesweg <[hidden email]>: >>>> Hi, >>>> >>>> as of today the main icon view has been replaced with the new implementation >>>> that has been under development for quite some time. >>>> I have taken care to go through the old code and port every single feature, >>>> but there is a lot of new code, so expect bugs and regressions. >>>> If you are running from current svn and find such a bug until beta1, please >>>> report it here shortly by mail, no need to flood b.k.o. I have not yet >>>> tested the majority of features, but will do in the next days. >>>> >>>> Issues: >>>> - Speed. (Talking about the 25000 pictures in the view situation). The idea >>>> is to make things faster. May things have become slower? They may. I have >>>> already eliminated performance issues with KCategorizedView. More to come. >>>> It seems that the view is the limiting factor and the model is well >>>> optimized. >>>> - The rate-on-hover feature is waiting to be ported >>>> - When new images are added in the background, currently the whole album is >>>> reloaded - incremental update is a missing feature. >>>> >>>> Marcel >>>> _______________________________________________ >>>> Digikam-devel mailing list >>>> [hidden email] >>>> https://mail.kde.org/mailman/listinfo/digikam-devel >>>> >>>> >>> >> > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
Marcel,
I find another bug : 1/ Make a selection in album. 2/ Select Copy from pop-up menu 3/ Go to another album 4/ Clic somewhere to have pop-up menu with Paste option 5/ It appear in another place over application, not behind mouse cursor. 6/ try to use paste option : nothing happen... Gilles 2009/5/16 Marcel Wiesweg <[hidden email]>: > Hi, > > as of today the main icon view has been replaced with the new implementation > that has been under development for quite some time. > I have taken care to go through the old code and port every single feature, > but there is a lot of new code, so expect bugs and regressions. > If you are running from current svn and find such a bug until beta1, please > report it here shortly by mail, no need to flood b.k.o. I have not yet > tested the majority of features, but will do in the next days. > > Issues: > - Speed. (Talking about the 25000 pictures in the view situation). The idea > is to make things faster. May things have become slower? They may. I have > already eliminated performance issues with KCategorizedView. More to come. > It seems that the view is the limiting factor and the model is well > optimized. > - The rate-on-hover feature is waiting to be ported > - When new images are added in the background, currently the whole album is > reloaded - incremental update is a missing feature. > > Marcel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Bugzilla from andi.clemens@gmx.net
> I can confirm, seems to be some race-condition.
> If you switch to another album, no image is actually selected. Look at the > edit action in the toolbar for example, it is disabled. > When you just rightclick on an item, it becomes selected (edit action in > toolbar is active now), but somehow the context menu has already been > created. Right-clicking the item again "fixes" the menu. > The ContextMenuHelper normally removed disabled actions, to avoid an even > bigger contextmenu. This is why some actions are not displayed. > > The actions are enabled in DigikamApp::slotImageSelected(), but the slot > seems to be called slightly after the contextmenu is created. > > I guess we had this problem also before the ModelView port, but since I > always click first on an item, I've never seen it. If this worked before, there was a good solution; if it never worked, we need to think about a new solution. Anyone has an old version, maybe 0.10 installed to quickly test? _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
The old version didn't work, too... just checked it...
Andi On Tuesday 19 May 2009 19:47:17 Marcel Wiesweg wrote: > > I can confirm, seems to be some race-condition. > > If you switch to another album, no image is actually selected. Look at > > the edit action in the toolbar for example, it is disabled. > > When you just rightclick on an item, it becomes selected (edit action in > > toolbar is active now), but somehow the context menu has already been > > created. Right-clicking the item again "fixes" the menu. > > The ContextMenuHelper normally removed disabled actions, to avoid an even > > bigger contextmenu. This is why some actions are not displayed. > > > > The actions are enabled in DigikamApp::slotImageSelected(), but the slot > > seems to be called slightly after the contextmenu is created. > > > > I guess we had this problem also before the ModelView port, but since I > > always click first on an item, I've never seen it. > > There is a timer to compress selection signals in DigikamView, so you are > quite right, DigikamView::slotDispatchImageSelected is called in the event > loop after the context menu event has been received. > If this worked before, there was a good solution; if it never worked, we > need to think about a new solution. Anyone has an old version, maybe 0.10 > installed to quickly test? _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
Marcel,
Why all Batch Process Image plugin menu entry are disable in Tools menu. Same for Batch Raw converter. Only Red Eyes Removal is enabled. Very strange... Gilles 2009/5/16 Marcel Wiesweg <[hidden email]>: > Hi, > > as of today the main icon view has been replaced with the new implementation > that has been under development for quite some time. > I have taken care to go through the old code and port every single feature, > but there is a lot of new code, so expect bugs and regressions. > If you are running from current svn and find such a bug until beta1, please > report it here shortly by mail, no need to flood b.k.o. I have not yet > tested the majority of features, but will do in the next days. > > Issues: > - Speed. (Talking about the 25000 pictures in the view situation). The idea > is to make things faster. May things have become slower? They may. I have > already eliminated performance issues with KCategorizedView. More to come. > It seems that the view is the limiting factor and the model is well > optimized. > - The rate-on-hover feature is waiting to be ported > - When new images are added in the background, currently the whole album is > reloaded - incremental update is a missing feature. > > Marcel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
> Marcel,
> > It's always reproducible when digikamrc file is deleted. Look effect : > > http://farm3.static.flickr.com/2356/3544954645_bd9fd7e114_o.png > > After to change icon size, problem disappears... > If you don't change icon size and restart digiKam, problem still here... _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Matthias Welwarsky
> Some problems here navigating the view with Arrow buttons: If you select > images with Shift plus Arrow buttons, you cannot cross the end of a row > with left/right arrows. Up/Down arrows seem to work. > Deleted images sometimes don't disappear from the view. > Metadata update when navigating pictures is slower than before and seems to > block the navigation. Is this now handled synchronously? > Lots of flickering when deleting images (full repaints, view is erased and > then completely redrawn). _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Bugzilla from mikmach@wp.pl
> album because "Show sub-albums" option isn't working. > Confirming issue with greyed out arrows in b-r corner. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
I don't think this has something to do with it. This happened for me in
gwenview quite often. I am doing something right in RemoveRedEyes that the other plugins don't do :D But I haven't figured out what it is. Andi On Tuesday 19 May 2009 22:19:27 Gilles Caulier wrote: > Marcel, > > Why all Batch Process Image plugin menu entry are disable in Tools > menu. Same for Batch Raw converter. Only Red Eyes Removal is enabled. > Very strange... > > Gilles > > 2009/5/16 Marcel Wiesweg <[hidden email]>: > > Hi, > > > > as of today the main icon view has been replaced with the new > > implementation that has been under development for quite some time. > > I have taken care to go through the old code and port every single > > feature, but there is a lot of new code, so expect bugs and regressions. > > If you are running from current svn and find such a bug until beta1, > > please report it here shortly by mail, no need to flood b.k.o. I have not > > yet tested the majority of features, but will do in the next days. > > > > Issues: > > - Speed. (Talking about the 25000 pictures in the view situation). The > > idea is to make things faster. May things have become slower? They may. I > > have already eliminated performance issues with KCategorizedView. More to > > come. It seems that the view is the limiting factor and the model is well > > optimized. > > - The rate-on-hover feature is waiting to be ported > > - When new images are added in the background, currently the whole album > > is reloaded - incremental update is a missing feature. > > > > Marcel > > _______________________________________________ > > Digikam-devel mailing list > > [hidden email] > > https://mail.kde.org/mailman/listinfo/digikam-devel > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
On Tuesday 19 May 2009 22:52:14 Marcel Wiesweg wrote:
> > Some problems here navigating the view with Arrow buttons: If you select > > images with Shift plus Arrow buttons, you cannot cross the end of a row > > with left/right arrows. Up/Down arrows seem to work. > > Should be fixed (it's default behavior that left/right does not cross row. > dont know why...) Yes, that's fixed. > > Deleted images sometimes don't disappear from the view. > > Will investigate Might be difficult to reproduce. I've seen it once only. > > Lots of flickering when deleting images (full repaints, view is erased > > and then completely redrawn). > > Yes, incremental update is waiting to be implemented. Currently, the album > is completely reloaded. It's a more complicated than all the other problems > mentioned here, but I have a plan to do it. Also, the album view is reset to the top of the album when you delete images. regards, matthias _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Matthias Welwarsky
On Sunday 17 May 2009 17:19:32 Matthias Welwarsky wrote:
> Another bug, (maybe more related to database model?): > Trying to adjust EXIF orientation brings up progress bar saying: "Updating > orientation in database..." or similar, then nothing. Thumbnail rotation > does not change. Progress bar never goes away, but application is still > responding. On next start, thumbnail still shows same orientation. This one is still partially there. The EXIF information is now changed correctly, but the thumbnail doesn't rotate. Images that had the correct EXIF info when downloaded are displayed correctly, those that have their information changed after download do not. regards, matthias _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Bugzilla from andi.clemens@gmx.net
> The old version didn't work, too... just checked it...
I think we introduced the timer because retrieving the list of all image infos and of the selected image infos was slow (it's still relatively slow, and of course scales with O(n)). For enabling the actions we only need the size of the selection list, which is fast to retrieve. We could split the signals and emit one of them directly, the other with the timer. Opinions? _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
Another problem:
1. Select a tag from the tagfolderview (although this is true for albumfolderview, too) 2. Set View->Sort Images->By Name 3. Scroll through the list. You will see that the first item of every recursively displayed album has been moved to the previous album. Ok nobody understood this :-) Example: Tag A Albums M N O P Q R S I select tag A which is in Albums N O R S Now the images are displayed like this: N1 N2 N3 O1 O2 O3 R1 R2 R3 R4 R5 S1 S2 S3 etc I hope you understand what I mean... if not, I'll do a screenshot. But most of the time these mails are rejected from the mailing list (which is quite annoying). Andi On Saturday 16 May 2009 18:00:23 Marcel Wiesweg wrote: > Hi, > > as of today the main icon view has been replaced with the new > implementation that has been under development for quite some time. > I have taken care to go through the old code and port every single feature, > but there is a lot of new code, so expect bugs and regressions. > If you are running from current svn and find such a bug until beta1, please > report it here shortly by mail, no need to flood b.k.o. I have not yet > tested the majority of features, but will do in the next days. > > Issues: > - Speed. (Talking about the 25000 pictures in the view situation). The idea > is to make things faster. May things have become slower? They may. I have > already eliminated performance issues with KCategorizedView. More to come. > It seems that the view is the limiting factor and the model is well > optimized. - The rate-on-hover feature is waiting to be ported > - When new images are added in the background, currently the whole album is > reloaded - incremental update is a missing feature. > > Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
> Album/refresh album : nothing happens. Previously it did mainly two things: - reread the current album from the db. But, if images are added to an album or removed, the view is updated automatically. So this is not needed. - delete all thumbnails. In my feeling, this should be labeled "Recreate thumbnails" or similar - trigger a collection scan of the current album - only applicable to physical albums, obviously _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Bugzilla from andi.clemens@gmx.net
> Another problem:
> > 1. Select a tag from the tagfolderview (although this is true for > albumfolderview, too) > 2. Set View->Sort Images->By Name > 3. Scroll through the list. > > You will see that the first item of every recursively displayed album has > been moved to the previous album. > Ok nobody understood this :-) ;-) And I'm sure it's my fault, off-by-one somewhere. Will fix it. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
2009/5/20 Marcel Wiesweg <[hidden email]>:
> >> Press F5 : nothing happens. >> Album/refresh album : nothing happens. > > This is not strictly a bug - it's a bit deliberately disabled. The question > is: what is refresh supposed to do? Previously, it reload only thumbs from current album. > Previously it did mainly two things: > - reread the current album from the db. But, if images are added to an album > or removed, the view is updated automatically. So this is not needed. > - delete all thumbnails. In my feeling, this should be labeled "Recreate > thumbnails" or similar yes > > Refresh could mean: > - trigger a collection scan of the current album - only applicable to > physical albums, obviously Why not... Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
| Free forum by Nabble | Edit this page |
