-2

Removed by supreme1012

In most ways this is pretty similar to digikam, and I doubt someone would make an entire new program from scratch for these differences. So in practice this amounts to a number of individual suggestions for digikam. So I think it would be better if you broke this up into individual suggestions for digikam and posted them as separate ideas in the forum. You can use the same pictures as reference in multiple idea, although please make it clear that you are doing so.

Another moderator or admin can approve this thread if they disagree, but in my opinion that is the best and approach and the most likely one to get results. Lumping all these suggestions together makes it hard to separate out the individual pieces for analysis and voting, hard to comment on specific changes, and impossible to give manageable-sized bug reports to the digikam developers.

Although I do agree in essence with TheBlackCat, I also understand how difficult it is for Supreme1012 to break it up in this way. Thus I've approved the idea - users can still discuss the "general feeling" of this idea, and based of that we can branch of some more digestable idea.s

removed by supreme1012

This idea is not much improving digiKam but nerfing it down. Almost 90% of the functionality what mockup presents are already available, not just by default settings. Some would never be implented.

And even that the idea is not directly for digiKam, it still is has all what digiKam has.

1. My idea is for a Photo Manager + (common tasks) Editor in one application. Whereas Digikam breaks it up into Digikam + Showfoto, which can be a hassle and messy

DigiKam has showFoto in different window. Because professionals and advanced users who has two (+1) monitor setups, needs to have one feature in one screen and other in second. Like you can have lighttable on right while albums on left. Or albums on left and editor on right. Not to mention that by separation we support more KDE SC technologies like virtual desktops, activities, Window Manager tabbing and many other KWin features. DigiKam wish to give the power to the user to customise the workflow and working environment like they wish/need. No matter do you have a netbook or 3x30" monitor setup.

2. I propose getting rid of the tabs on the sides, which I see as a major usability issue. To accomplish these same functions I created a button to show/hide the panel as well as a way to switch between different panels easily by clicking the dropdown box next to the button. Some possible panels could be Information(properties, tags, and metadata), Modify(tools, effects, and colors), People(face recognition and tagging), Date(timeline and calendar), and Location(geolocation tools). With the ability to add or remove any or all panel options from the dropdown button.

Even that the usability problem what you talk is the vertical text. The menus still works much better way than adding a two new buttons to toolbar what causes more clicks, dropdown links and does not allow easily with single click to hide(unhide) the panel or switch from view ot other. The idea to have a stable tab order and position (left/right) is well discussed. Example the power what three different tags panels positioned to both side panels gives something what this wish does not give at all. Example you can not first search by tag, then filter the tag and then add a new tag or any other function to search results. Same thing is with other tools as well that you can very easily combine them what is the critical feature for those who has hundreds of thousands photos and not just few hundreds.

And in your wish, the user is forced to have a toolbar and is not allowed to have only a menubar or even having a menubar and toolbar hidden (like many does use it such way).

3. Digikam has a ton of tools all crammed into different menus and buttons and panels. My mockups show a uniform and easily accessible way to handle tasks, with the focus on displaying the most common jobs while still being able to perform more advanced functions.

There has been much ideas (like yours what is based to mine mockups) what already have polished the UI or is going to be implented in future versions (the roadmap is open but still strick to base plans. Like now with the GSOC time there is own branch to the 1.4)

4. Digikam has an internal database that can be slow and cumbersome at times. My idea is to harness KDE4's technologies to make things faster. eg; use Dolphin's native thumbnails since they seem to display 50x faster than Digikam's.

Actually digiKam just changed away from the KDE platform own thumbnailing. It used the same thumbnailing what dolphin used and was much slower because when the file got changed, edited, renamed or directory got changed it needed to get refreshed again. Now digiKam use own database what is much faster, if I remember correctly it is 10x faster than dolphin.

5. My proposal also includes using Nepomuk to show and change metadata for images

Nepomuk does not support well writing standard XMP, EXIV, IPTC tags. There have been a limited Nepomuk support but it works well only from digiKam -> nepomuk but not otherway because limitations. The Nepomuk is still lacking the features what other photo organisation and editing applications needs and use (digiKam, Lightroom, Photoshop etc). There are plans to implent nepomuk well but not until Nepomuk itself is has all the features what are needed by photo management applications.

6. Currently Digikam works separately from Kipi-plugins, even though they're developed together. This can be a strength, but my proposal would make the plugins a dependency of my photo management application and integrate all of the great work that's been done on the Kipi-plugins to easily be able to offer tools and effects right from within the program without having to write the code from scratch.

Why user should have kipi-plugins if not wanted or then other application to get kipi-plugins? The kipi-plugins are developed by same people who makes digiKam. The reason that they are plugins is that they can be used same time with other applications without need to write them scratch. Like Gwenview and KPhotoAlbum can use those plugins as well the digiKam use. The modularity is power where one tool does one thing well and user can join them and developers can choose what features to take to own application. Same time all gets benefits when one developer improves the Kipi-Plugins code.

7. My interface focuses on a clean and clutter free layout, with the main focus on browsing through your images, and all tasks and jobs pushed into the sidepanel, which has the ability to be hidden when not needed.

Exactly what is in digiKam already. What you say "clutter" is the power what you can not find almost anywhere else as simply and easy way. But you have opinions and digiKam has its users needs. Just attaching tools to one UI or combine them does not make the UI better.

8. My mockups show all filters and search bars at the top. This is more consistent with the rest of KDE4 and is just better usability wise. Search results should be displayed below the search box, making it less distance between clicking on the search bar and then clicking on the search results.

That was discussed long time ago before the searchboxes were implented. There were many different usability reasons to make it such as it is now. One was it is constantily same in all places. So users do not end up having sometimes filter/search bar top and sometimes down. There are many elements what are following the HIG and when you need to get 20 features and functions together without loosing half of them, there still must be very small choises for common good.

9. The look of Digikam is based on a theming platform. While this can be nice, in order to simplify coding and better integrate with KDE4, my idea is to use the color scheme and appearance settings of the users configuration to automatically blend with the other applications and desktop.

You might not have checked the digiKam code how it is written? It is all written by hand, without Qt Designer and suchs IDE's what can mess the code. DigiKam use KDE Platform, it so on has all the features what any other KDE Application does. Only difference is that is as well has own support for different color schemas what is needed. It does not sacrifice at all the quality of the code, make it harder to code or how well digiKam fits to anywhere where KDE Apps fits.

By default digiKam use exactly the settings what user has set from systemsettings. Color schema, style and even icons if the users icon set just has the digiKam own icons done.

10. Not yet shown in my mockups, I intend to make it possible to browse through your albums not just with the tree view hierarchy but also show a "flat view" option that would show all of your photo albums on one level regardless of the folder's disk location

There are few wish reports for this and there has been made progress to allow such. It is coming in future versions because the view is being rewritten for Qt4 (there is still Qt3 code) and same time that is possible well. Already it is possible to see when you select the root album and set the view to show sub-albums.

The idea as well for the tree is that user can have multiple album locations. Photos can be placed on external drive, NFS/SMB server or keep them on different harddrives, optical medias or even different directories. The backup system (what is coming) is easier to maintain and user has full control to the photos, not just trough digiKam but with any other application as well. User is not tied to digiKam itself but can use filemanager (dolphin/konqueror/nautilus etc) to browse albums and edit or manage them with any other application. Handling photos is easy to do with other tools as well than just digiKam.

11. What first got me to start working on these mockups was how Digikam handled tagging. My proposal would use an easy check/uncheck function to add or remove tags from an image or group of images. This is based primarily from Picasa. For more explanation of how the tagging would work, refer to this brainstorm post "brainstorm.php#idea88018_page1"

And digiKam does not allow that already? Just select photos and click the tag what you want and it gets automatically applied if you have just set it so from settings. For safety procasions the automatic metadata writing is disabled so new computer user does not make so easily mistakes by removing tags from photos by just mistakenly unchecking the tag but gets prompt.

DigiKam allows far more easily tagging photos (single or many) many different ways. Were they shown from album, date, location or any other search way, including tag search. All because the tag search, filtering and tagging itself are separated functiosn and not just single one.

The ideas in this wish would work better way in some other very simple photo management applications but they do not have such features what this idea actually tries to solve.

removed by supreme1012

Marked as Invalid as idea has been removed by author.