In the latest KDE Commit-Digest:
- Work on the CSV importer in KMyMoney
- Work across the board in Calligra, including improved PPT format support
- Work on video and sending/recieving files with the Yahoo protocol in Kopete amongst other changes
- Work on search history support in KDevPlatform
- New Booksmarks Manager (including support for importing bookmarks) in Marble, amongst many bug fixes
- Much work throughout Kst including optimisations
- KFileDialog now automatically chooses file type from typed extension
- Work on the Public Transport Plasma data engine
- Improvements in ad blocking code in KWebkitPart
- Features and bugfixing in KDE-PIM, Lionmail, and Knights
- Fixes for header-protected RAR and 7z files in Ark
- Audio streaming support in Gluon
- Optimisation and feature work in Digikam
- Optimisations in the Webslice Plasma widget
- All launcher config reading/saving has been moved into the new Group Manager
- KDE-SDK's Kdesrc-Build moves to Git
- KDE-PIM libs move to Git
- Fsview is now Qt3Support-free
- Bugfixes in Gwenview, Konsole, KPat, Rekonq, Muon, Oxygen-Gtk and throughout Plasma and its addons.
... not only. there are 3 new important feature in 2.0 :
- Tag keyboard shortcuts support.
- Color Labels support to improve photograph workfow (as Lightroom and Aperture).
- Pick Labels support to improve photograph selection (as Lightroom and Aperture)
Gilles, thanks for pointing out!
Within the hundreds and sometimes thousands of commit messages it is sometimes difficult for us from the Commit-Digest team to identify the interesting and relevant ones. In particular, if the commit message text is very short, sounds very technical or the reviewer lacks the knowledge whether a commit is interesting / important.
If a developer wants to increase chances that a particular commit is included in the Commit-Digest he can do the following:
Furthermore, the above is also helpful for the editor writing the introduction.
HINT: the Commit-Digest team is always happy to receive a "featured article" :-)
And the Commit-Digest team always looks for : fresh blood!
>add a longer description text why the commit is interesting
i try to do it...
>refer to a bug report / wishlist item
I always do it, I'm always work against bugzilla entries.
>reference to a screenshot
Sometime i do it. I will post more screen-shot in the future...
>add an identifier, e.g., "[Digest]" to point out that the message >should be included in the Commit Digest
AHHH. I'm waiting something like that since a long time. Please make an official git commit tag to redirect/filter right entries. All developers must use the same tag here.
We're implementing a standard git commit template for kde core that includes all the current tags like BUG and FEATURE as a reminder to devs. The FEATURE tag if used consistently would be a good one to look for, but if you want a specific tag for the digest let me know and I'll add it.
As a Commit Digest reviewer/editor I would be in favor of having a "digest" tag. Especially if developers would find it useful as well. It would certainly help ensure that particularly important commits don't get missed!
Yes! This is something we have been discussing for quite a while now, and its something that wouldn't be difficult to implement on my end, as long as tags are consistent.
I propose that the tags always be uppercase, so in this case:
DIGEST (this could be the generic tag)
For bugs, this is really important: currently, people use lots of different formats like "BUG:99999" (good), "Bug: 99999", even "bug 99999" - you can imagine how hard it is to pull this one out of a body of text!
Can we enforce one standard and shame the repeat offenders?
Send me an email at danny at commit-digest.org when you've got a final proposal!
Yup, a second thanks for pointing those out, Gilles. Sorry for missing them!
Thanks for you hard work in digikam, it is an amazing app for a young photographer like me :)
Some comments about the UI to improve it (from my POV of course...)
- There are so many buttons all arround the interface (on the right side of the "tags" field, on the down side of the app, etcetera. Maybe the interface could be cleaner, so it is easier to understand at a first sight
- There is lost space under the "my albums" field and with the "Tags" field... maybe they can share the same area, one under the other, but with one field for both (only one scrollbar when necessary)
- Every Tag in "my tags" has a label in the left side of the text. Is it really necessary? it clutters the UI
- The left bar looks old. Amarok had a similar one, and it improved it a lot with a new method: http://amarok.kde.org/files/amarok2.4.0.png
- Usually the "search" fields are on the top of the screen... They are easilly recognizable
- The borders of the photos are very "hard". Maybe they can be softer if you use the color of the border for the background color of the image, and avoid all the borders
- Using a grey background for the images field, and some shadows for the photos (like gwenview) would make the app also softer (see http://gwenview.sourceforge.net/screenshots.php?action=view&album=/2.4&p... )
- The scrollbar of the preview panel clutter the UI. Maybe something like the "add plasmoids" from plasma could be better (see http://gabuntu.files.wordpress.com/2010/07/plasmoids4.png )
- Using "grey / white" colors for every line of the "my tags" or "my albums" would make the different lines easier to read (see http://amarok.kde.org/files/amarok2.4.0.png again)
Again, thank you for the work done with this amazing app.
Regards from Spain,
>- There are so many buttons all around the interface (on the right >side of the "tags" field, on the down side of the app, etcetera. Maybe >the interface could be cleaner, so it is easier to understand at a >first sight
The interface is clean already. Photo work-flow is a complex stuff. Take a look to pro Lightroom, Aperture, ACDSee, photostation, application and you will see how GUI are bloated everywhere.
We trying to keep in mind this : all pro application provide complex gui. We trying to not reproduce this way in digiKam.
digiKam is not Gwenview. If Photo work-flow is too complex for you, use Gwenview... digiKam is pro photo dedicated software. It's more than Picasa, F-Spot, or Shotwell.
>- There is lost space under the "my albums" field and with the >"Tags" field... maybe they can share the same area, one under the >other, but with one field for both (only one scrollbar when
Which one exactly ? Take a shot please...
>- Every Tag in "my tags" has a label in the left side of the text. >Is it really necessary? it clutters the UI
This can be optimized, yes...
>- The left bar looks old. Amarok had a similar one, and it improved >it a lot with a new method: http://amarok.kde.org/files
Definitively, no. I'm not Amarok user, i prefer Clementine GUI. I'm completely lost with Amarok sidebar. I hate it. It's unsuitable. Sorry...
Current digiKam sidebar is clear. You see where each main component are located in GUI !
>- Usually the "search" fields are on the top of the screen... They >are easily recognizable
Not true for all, especially in photo management program.
>- The borders of the photos are very "hard". Maybe they can be >softer if you use the color of the border for the background color >of the image, and avoid all the borders
Which border exactly ? take a screen-shot please....
>- Using a grey background for the images field, and some shadows for >the photos (like gwenview) would make the app also softer (see >http://gwenview.sourceforge.net/screenshots.php?action=view&album=
digiKam use same border code than gwenview for icon view...
About color frame, it's not agree, since digiKam support Color Labels, which add colored frame around icon view item...
>- The scrollbar of the preview panel clutter the UI. Maybe something >like the "add plasmoids" from plasma could be better (see >http://gabuntu.files.wordpress.com/2010/07/plasmoids4.png )
It's fixed with 2.0.0, using model/view.
>- Using "grey / white" colors for every line of the "my tags" or "my >albums" would make the different lines easier to read (see >http://amarok.kde.org/files/amarok2.4.0.png again)
Definitively no. It's tree-view not a list view. Look like Dolphin in folder tree view do not use it. This bloat GUI, i tested it...