Re: IPTC

[Gilles Caulier-4]

2008/11/30 Andi Clemens <[hidden email]>

Hi,

somebody in IRC tried to remove IPTC tags, and it was not working. So I
checked for myself and it is true: even in digiKam3 IPTC data can't be
removed at the moment (Image->Metadata->Remove IPTC).

Is it broken?

Which version of Exiv2 and libkexiv2. I think than current ibkexiv2 is fixed (note: both KDE3 and KDE4)

If you use a stable libkexiv2, problem can be present. This is want mean that libkexiv2 for KDE3 need to be released soon.


 

Another note on splitter issue:

Patrick asked why we use toBase64 here:
http://lxr.kde.org/source/extragear/graphics/digikam/digikam/albumwidgetstack.cpp#232

Could this be the source of the problem?

yes, I have suspected that. If i'm not too wrong, i think MArcel as interoduced this code, but i'm not sure. So, i cannot said why we use it exactly...
 

Also where are we saving the state of the left and right sidebar splitter?
We only have 3 entries in digikamrc, shouldn't this be 5 at least?

1 for thumbbar splitter
2 for sidebar splitter in mainwindow
2 for sidebar splitter in imageeditor

But there is only this method to save their states:
http://lxr.kde.org/source/extragear/graphics/digikam/libs/widgets/common/sidebar.cpp#433

This method is the same for left and right, or isn't it? If so, isn't this
wrong?

yes. code is factorized at this place.

I CC this mail to devel Mailing list for more visibility...

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/11/30 Andi Clemens <[hidden email]>

Hi,

somebody in IRC tried to remove IPTC tags, and it was not working. So I
checked for myself and it is true: even in digiKam3 IPTC data can't be
removed at the moment (Image->Metadata->Remove IPTC).

Is it broken?

Another note on splitter issue:

Patrick asked why we use toBase64 here:
http://lxr.kde.org/source/extragear/graphics/digikam/digikam/albumwidgetstack.cpp#232

Could this be the source of the problem?

Certainly... Perhaps this code is a side effect from KDE3 port. If we follow Qt4 doc here:

http://doc.trolltech.com/4.4/qsplitter.html#restoreState

The code do not use base64 transformation... but we can read:

"A failure to restore the splitter's layout may result from either invalid or out-of-date data in the supplied byte array."

What is it?

Gilles

PS: i fork this message in ML for better visibility

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/12/1 Gilles Caulier <[hidden email]>

2008/11/30 Andi Clemens <[hidden email]>

Hi,

somebody in IRC tried to remove IPTC tags, and it was not working. So I
checked for myself and it is true: even in digiKam3 IPTC data can't be
removed at the moment (Image->Metadata->Remove IPTC).

Is it broken?

Another note on splitter issue:

Patrick asked why we use toBase64 here:
http://lxr.kde.org/source/extragear/graphics/digikam/digikam/albumwidgetstack.cpp#232

Could this be the source of the problem?

Certainly... Perhaps this code is a side effect from KDE3 port. If we follow Qt4 doc here:

http://doc.trolltech.com/4.4/qsplitter.html#restoreState

The code do not use base64 transformation... but we can read:

"A failure to restore the splitter's layout may result from either invalid or out-of-date data in the supplied byte array."

What is it?

Also, look code from sidebar class to restore and save splitter sate. i use too base64 transformations:

http://lxr.kde.org/source/extragear/graphics/digikam/libs/widgets/common/sidebar.cpp#420

...but, i have never see any problem with vertical splitters used by sidebar.

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Monday 01 December 2008 11:05:28 Gilles Caulier wrote:

> > Certainly... Perhaps this code is a side effect from KDE3 port. If we
> > follow Qt4 doc here:
> >
> > http://doc.trolltech.com/4.4/qsplitter.html#restoreState
> >
> > The code do not use base64 transformation... but we can read:
> >
> > "A failure to restore the splitter's layout may result from either
> > invalid or out-of-date data in the supplied byte array."
> >
> > What is it?

Sounds like this broken behavior is normal and expected :-)
I don't really understand that statement...???

Andi


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/12/1 Andi Clemens <[hidden email]>

On Monday 01 December 2008 11:05:28 Gilles Caulier wrote:
> > Certainly... Perhaps this code is a side effect from KDE3 port. If we
> > follow Qt4 doc here:
> >
> > http://doc.trolltech.com/4.4/qsplitter.html#restoreState
> >
> > The code do not use base64 transformation... but we can read:
> >
> > "A failure to restore the splitter's layout may result from either
> > invalid or out-of-date data in the supplied byte array."
> >
> > What is it?

Sounds like this broken behavior is normal and expected :-)
I don't really understand that statement...???

One important point : in sidebar class, we re-implement QSplitter::saveSate() and QSplitter::restoreSate().

In AlbumWidgetStack, we just call the methods as well....

Perhaps the problem is here...

The big question is why we use base64() here.

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Ok I replaced the code now and it seems to work, even the broken rc file from
the bugreport.

I will commit it...

Andi


On Monday 01 December 2008 11:08:15 Andi Clemens wrote:

> On Monday 01 December 2008 11:05:28 Gilles Caulier wrote:
> > > Certainly... Perhaps this code is a side effect from KDE3 port. If we
> > > follow Qt4 doc here:
> > >
> > > http://doc.trolltech.com/4.4/qsplitter.html#restoreState
> > >
> > > The code do not use base64 transformation... but we can read:
> > >
> > > "A failure to restore the splitter's layout may result from either
> > > invalid or out-of-date data in the supplied byte array."
> > >
> > > What is it?
>
> Sounds like this broken behavior is normal and expected :-)
> I don't really understand that statement...???
>
> Andi
>
>
> _______________________________________________
> 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

I will wait for Marcel's answer... so I'll keep the patch in my GIT repo for
now...

Andi

On Monday 01 December 2008 11:20:31 Gilles Caulier wrote:

> 2008/12/1 Andi Clemens <[hidden email]>
>
> > On Monday 01 December 2008 11:05:28 Gilles Caulier wrote:
> > > > Certainly... Perhaps this code is a side effect from KDE3 port. If we
> > > > follow Qt4 doc here:
> > > >
> > > > http://doc.trolltech.com/4.4/qsplitter.html#restoreState
> > > >
> > > > The code do not use base64 transformation... but we can read:
> > > >
> > > > "A failure to restore the splitter's layout may result from either
> > > > invalid or out-of-date data in the supplied byte array."
> > > >
> > > > What is it?
> >
> > Sounds like this broken behavior is normal and expected :-)
> > I don't really understand that statement...???
>
> One important point : in sidebar class, we re-implement
> QSplitter::saveSate() and QSplitter::restoreSate().
>
> In AlbumWidgetStack, we just call the methods as well....
>
> Perhaps the problem is here...
>
> The big question is why we use base64() here.
>
> Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Note : look code from Qt4.4.3::QSplitter class :

QByteArray QSplitter::saveState() const
{
    int version = 0;
    QByteArray data;
    QDataStream stream(&data, QIODevice::WriteOnly);

    stream << qint32(SplitterMagic);
    stream << qint32(version);
    stream << sizes();
    stream << childrenCollapsible();
    stream << qint32(handleWidth());
    stream << opaqueResize();
    stream << qint32(orientation());
    return data;
}

bool QSplitter::restoreState(const QByteArray &state)
{
    Q_D(QSplitter);
    int version = 0;
    QByteArray sd = state;
    QDataStream stream(&sd, QIODevice::ReadOnly);
    QList<int> list;
    bool b;
    qint32 i;
    qint32 marker;
    qint32 v;

    stream >> marker;
    stream >> v;
    if (marker != SplitterMagic || v != version)
        return false;

    stream >> list;
    setSizes(list);

    stream >> b;
    setChildrenCollapsible(b);

    stream >> i;
    setHandleWidth(i);

    stream >> b;
    setOpaqueResize(b);

    stream >> i;
    setOrientation(Qt::Orientation(i));
    d->doResize();

    return true;
}

==> base64 stuff is never used here.

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Yes, that' why I removed all calls to fromBase64() and toBase64().

Andi


On Monday 01 December 2008 11:39:26 Gilles Caulier wrote:

> Note : look code from Qt4.4.3::QSplitter class :
>
> QByteArray QSplitter::saveState() const
> {
>     int version = 0;
>     QByteArray data;
>     QDataStream stream(&data, QIODevice::WriteOnly);
>
>     stream << qint32(SplitterMagic);
>     stream << qint32(version);
>     stream << sizes();
>     stream << childrenCollapsible();
>     stream << qint32(handleWidth());
>     stream << opaqueResize();
>     stream << qint32(orientation());
>     return data;
> }
>
> bool QSplitter::restoreState(const QByteArray &state)
> {
>     Q_D(QSplitter);
>     int version = 0;
>     QByteArray sd = state;
>     QDataStream stream(&sd, QIODevice::ReadOnly);
>     QList<int> list;
>     bool b;
>     qint32 i;
>     qint32 marker;
>     qint32 v;
>
>     stream >> marker;
>     stream >> v;
>     if (marker != SplitterMagic || v != version)
>         return false;
>
>     stream >> list;
>     setSizes(list);
>
>     stream >> b;
>     setChildrenCollapsible(b);
>
>     stream >> i;
>     setHandleWidth(i);
>
>     stream >> b;
>     setOpaqueResize(b);
>
>     stream >> i;
>     setOrientation(Qt::Orientation(i));
>     d->doResize();
>
>     return true;
> }
>
> ==> base64 stuff is never used here.
>
> Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/12/1 Gilles Caulier <[hidden email]>

Note : look code from Qt4.4.3::QSplitter class :

QByteArray QSplitter::saveState() const
{
    int version = 0;
    QByteArray data;
    QDataStream stream(&data, QIODevice::WriteOnly);

    stream << qint32(SplitterMagic);
    stream << qint32(version);
    stream << sizes();
    stream << childrenCollapsible();
    stream << qint32(handleWidth());
    stream << opaqueResize();
    stream << qint32(orientation());
    return data;
}

bool QSplitter::restoreState(const QByteArray &state)
{
    Q_D(QSplitter);
    int version = 0;
    QByteArray sd = state;
    QDataStream stream(&sd, QIODevice::ReadOnly);
    QList<int> list;
    bool b;
    qint32 i;
    qint32 marker;
    qint32 v;

    stream >> marker;
    stream >> v;
    if (marker != SplitterMagic || v != version)
        return false;

    stream >> list;
    setSizes(list);

    stream >> b;
    setChildrenCollapsible(b);

    stream >> i;
    setHandleWidth(i);

    stream >> b;
    setOpaqueResize(b);

    stream >> i;
    setOrientation(Qt::Orientation(i));
    d->doResize();

    return true;
}

==> base64 stuff is never used here.

Gilles

To resume : i think to use QByteArray::toBase64() is wrong here...

But we use it too in :

- sidebar.cpp 
- lighttablewindow.cpp.
- editorwindow.cpp

I think these entries need to be fixed too in the same way.

Best

Gilles




_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

I've done this already... and I guess the window size is saved wrong, too...
when I look into the digikamrc file now, there is one base64 value in it:

[General Settings]
State=AAAA/wAAAAD9AAAAAAAAA7gAAAI4AAAABAAAAAQAAAAIAAAACPwAAAABAAAAAgAAAAEAAAAOAFQAbwBvAGwAQgBhAHIBAAAAAAAAA7gAAAAAAAAAAA==

I will change this, too, because at my machine digikam never starts maximized,
although I quit it in maximized window state.

Andi

On Monday 01 December 2008 11:44:55 Gilles Caulier wrote:

> 2008/12/1 Gilles Caulier <[hidden email]>
>
> > Note : look code from Qt4.4.3::QSplitter class :
> >
> > QByteArray QSplitter::saveState() const
> > {
> >     int version = 0;
> >     QByteArray data;
> >     QDataStream stream(&data, QIODevice::WriteOnly);
> >
> >     stream << qint32(SplitterMagic);
> >     stream << qint32(version);
> >     stream << sizes();
> >     stream << childrenCollapsible();
> >     stream << qint32(handleWidth());
> >     stream << opaqueResize();
> >     stream << qint32(orientation());
> >     return data;
> > }
> >
> > bool QSplitter::restoreState(const QByteArray &state)
> > {
> >     Q_D(QSplitter);
> >     int version = 0;
> >     QByteArray sd = state;
> >     QDataStream stream(&sd, QIODevice::ReadOnly);
> >     QList<int> list;
> >     bool b;
> >     qint32 i;
> >     qint32 marker;
> >     qint32 v;
> >
> >     stream >> marker;
> >     stream >> v;
> >     if (marker != SplitterMagic || v != version)
> >         return false;
> >
> >     stream >> list;
> >     setSizes(list);
> >
> >     stream >> b;
> >     setChildrenCollapsible(b);
> >
> >     stream >> i;
> >     setHandleWidth(i);
> >
> >     stream >> b;
> >     setOpaqueResize(b);
> >
> >     stream >> i;
> >     setOrientation(Qt::Orientation(i));
> >     d->doResize();
> >
> >     return true;
> > }
> >
> > ==> base64 stuff is never used here.
> >
> > Gilles
>
> To resume : i think to use QByteArray::toBase64() is wrong here...
>
> But we use it too in :
>
> - sidebar.cpp
> - lighttablewindow.cpp.
> - editorwindow.cpp
>
> I think these entries need to be fixed too in the same way.
>
> Best
>
> Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Marcel, any comment on why we use toBase64() methods to save splitter state?
Otherwise I will commit the changes to SVN, for me it works fine in my GIT
repo, even with "broken" digikamrc files.

Andi

On Monday 01 December 2008 11:51:09 Andi Clemens wrote:

> I've done this already... and I guess the window size is saved wrong,
> too... when I look into the digikamrc file now, there is one base64 value
> in it:
>
> [General Settings]
> State=AAAA/wAAAAD9AAAAAAAAA7gAAAI4AAAABAAAAAQAAAAIAAAACPwAAAABAAAAAgAAAAEAA
>AAOAFQAbwBvAGwAQgBhAHIBAAAAAAAAA7gAAAAAAAAAAA==
>
> I will change this, too, because at my machine digikam never starts
> maximized, although I quit it in maximized window state.
>
> Andi
>
> On Monday 01 December 2008 11:44:55 Gilles Caulier wrote:
> > 2008/12/1 Gilles Caulier <[hidden email]>
> >
> > > Note : look code from Qt4.4.3::QSplitter class :
> > >
> > > QByteArray QSplitter::saveState() const
> > > {
> > >     int version = 0;
> > >     QByteArray data;
> > >     QDataStream stream(&data, QIODevice::WriteOnly);
> > >
> > >     stream << qint32(SplitterMagic);
> > >     stream << qint32(version);
> > >     stream << sizes();
> > >     stream << childrenCollapsible();
> > >     stream << qint32(handleWidth());
> > >     stream << opaqueResize();
> > >     stream << qint32(orientation());
> > >     return data;
> > > }
> > >
> > > bool QSplitter::restoreState(const QByteArray &state)
> > > {
> > >     Q_D(QSplitter);
> > >     int version = 0;
> > >     QByteArray sd = state;
> > >     QDataStream stream(&sd, QIODevice::ReadOnly);
> > >     QList<int> list;
> > >     bool b;
> > >     qint32 i;
> > >     qint32 marker;
> > >     qint32 v;
> > >
> > >     stream >> marker;
> > >     stream >> v;
> > >     if (marker != SplitterMagic || v != version)
> > >         return false;
> > >
> > >     stream >> list;
> > >     setSizes(list);
> > >
> > >     stream >> b;
> > >     setChildrenCollapsible(b);
> > >
> > >     stream >> i;
> > >     setHandleWidth(i);
> > >
> > >     stream >> b;
> > >     setOpaqueResize(b);
> > >
> > >     stream >> i;
> > >     setOrientation(Qt::Orientation(i));
> > >     d->doResize();
> > >
> > >     return true;
> > > }
> > >
> > > ==> base64 stuff is never used here.
> > >
> > > Gilles
> >
> > To resume : i think to use QByteArray::toBase64() is wrong here...
> >
> > But we use it too in :
> >
> > - sidebar.cpp
> > - lighttablewindow.cpp.
> > - editorwindow.cpp
> >
> > I think these entries need to be fixed too in the same way.
> >
> > Best
> >
> > Gilles
>
> _______________________________________________
> 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

[Marcel Wiesweg]

> Marcel, any comment on why we use toBase64() methods to save splitter
> state? Otherwise I will commit the changes to SVN, for me it works fine in
> my GIT repo, even with "broken" digikamrc files.
>
> Andi

We get raw binary data from QSplitter, and use toBase64 to encode it to ASCII
to store it in the config file. We use toBase64 before we store to KConfig
and use fromBase64 after reading from KConfig.
I dont know any more where we took that from or if I made this up myself, and
I dont know if this is strictly necessary. Possibly KConfig can perfectly
well store raw binary data.
If you can confirm that bugs are caused by this and after removal the problems
are solved, and configuration is always saved, then please commit.
(Keep in mind that when you remove fromBase64 the "broken" digikamrc files
will fail to load at all.)

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Monday 01 December 2008 21:13:38 Marcel Wiesweg wrote:

> > Marcel, any comment on why we use toBase64() methods to save splitter
> > state? Otherwise I will commit the changes to SVN, for me it works fine
> > in my GIT repo, even with "broken" digikamrc files.
> >
> > Andi
>
> We get raw binary data from QSplitter, and use toBase64 to encode it to
> ASCII to store it in the config file. We use toBase64 before we store to
> KConfig and use fromBase64 after reading from KConfig.
> I dont know any more where we took that from or if I made this up myself,
> and I dont know if this is strictly necessary. Possibly KConfig can
> perfectly well store raw binary data.
> If you can confirm that bugs are caused by this and after removal the
> problems are solved, and configuration is always saved, then please commit.
> (Keep in mind that when you remove fromBase64 the "broken" digikamrc files
> will fail to load at all.)

No, they load perfectly... I assume that the SplitterState config vars will
not be read at all (because they are unknown now) and the default values will
be used. After closing digiKam, the new SplitterState will be saved.

OK I will commit it then...

Andi



>
> 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

Somehow I'm not sure if it really fixes the splitter problems... I had the
issue just 2 minutes ago... AGAIN!
Now I don't know if I had messed up my digikamrc file or if it is the same old
bug we are hunting for moths now.

I will not commit it and test it a little more. Next I will convert from KDE3
to KDE4, it should fail then...
I will keep you informed.

Andi

On Monday 01 December 2008 21:21:50 Andi Clemens wrote:

> On Monday 01 December 2008 21:13:38 Marcel Wiesweg wrote:
> > > Marcel, any comment on why we use toBase64() methods to save splitter
> > > state? Otherwise I will commit the changes to SVN, for me it works fine
> > > in my GIT repo, even with "broken" digikamrc files.
> > >
> > > Andi
> >
> > We get raw binary data from QSplitter, and use toBase64 to encode it to
> > ASCII to store it in the config file. We use toBase64 before we store to
> > KConfig and use fromBase64 after reading from KConfig.
> > I dont know any more where we took that from or if I made this up myself,
> > and I dont know if this is strictly necessary. Possibly KConfig can
> > perfectly well store raw binary data.
> > If you can confirm that bugs are caused by this and after removal the
> > problems are solved, and configuration is always saved, then please
> > commit. (Keep in mind that when you remove fromBase64 the "broken"
> > digikamrc files will fail to load at all.)
>
> No, they load perfectly... I assume that the SplitterState config vars will
> not be read at all (because they are unknown now) and the default values
> will be used. After closing digiKam, the new SplitterState will be saved.
>
> OK I will commit it then...
>
> Andi
>
> > 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

Bad news :-(
This patch doesn't help, and some of our old bugs are still available, too.

I copied my KDE3 rc file into the KDE4 folder and let digikam convert the
database and the rc file (with and without this patch).

After the conversion was finished, I could see my tags and albums, but no
thumbnails (kioslave is working of course). Switching between tags, date and
album view doesn't help. Also scanning for new images is not bringing back
the thumbnails. I had to restart.

After that, thumbnails are visible, BUT: Clicking on them will not display
anything. I have to resize the splitter again to see anything.
I would say something goes wrong here while converting, would make sense, but
why can't I see thumbnails on first start?

I have turned on the displaying of the total numbers of images in a folder,
every folder has a (0) label beside itself. This means that the images are
not recognized at all, it is not just a displaying problem.

So actually two of our most annoying bugs are still present: No images on
first start (after conversion) and the splitter bug (DAMN YOU SPLITTER :-))

Andi

On Monday 01 December 2008 21:41:44 Andi Clemens wrote:

> Somehow I'm not sure if it really fixes the splitter problems... I had the
> issue just 2 minutes ago... AGAIN!
> Now I don't know if I had messed up my digikamrc file or if it is the same
> old bug we are hunting for moths now.
>
> I will not commit it and test it a little more. Next I will convert from
> KDE3 to KDE4, it should fail then...
> I will keep you informed.
>
> Andi
>
> On Monday 01 December 2008 21:21:50 Andi Clemens wrote:
> > On Monday 01 December 2008 21:13:38 Marcel Wiesweg wrote:
> > > > Marcel, any comment on why we use toBase64() methods to save splitter
> > > > state? Otherwise I will commit the changes to SVN, for me it works
> > > > fine in my GIT repo, even with "broken" digikamrc files.
> > > >
> > > > Andi
> > >
> > > We get raw binary data from QSplitter, and use toBase64 to encode it to
> > > ASCII to store it in the config file. We use toBase64 before we store
> > > to KConfig and use fromBase64 after reading from KConfig.
> > > I dont know any more where we took that from or if I made this up
> > > myself, and I dont know if this is strictly necessary. Possibly KConfig
> > > can perfectly well store raw binary data.
> > > If you can confirm that bugs are caused by this and after removal the
> > > problems are solved, and configuration is always saved, then please
> > > commit. (Keep in mind that when you remove fromBase64 the "broken"
> > > digikamrc files will fail to load at all.)
> >
> > No, they load perfectly... I assume that the SplitterState config vars
> > will not be read at all (because they are unknown now) and the default
> > values will be used. After closing digiKam, the new SplitterState will be
> > saved.
> >
> > OK I will commit it then...
> >
> > Andi
> >
> > > 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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Andi,

Undependetly of spliter size bug, i cannot find an fine explication why the image is not displayed in case of splitter size is null (thumbbar not visible).

This is not logic to not show preview image here. I suspect that zoom level (from status bar) has an invalid value at first init. later, it is relevant of preview widget size to be initialized properly (when splitter is resized).

To resume my idea, i suspect a race condition between zoom level and preview widget/Splitter/thumbbar are displayed (initialized).

Can you feel my viewpoint ?

Gilles

2008/12/2 Andi Clemens <[hidden email]>

Bad news :-(
This patch doesn't help, and some of our old bugs are still available, too.

I copied my KDE3 rc file into the KDE4 folder and let digikam convert the
database and the rc file (with and without this patch).

After the conversion was finished, I could see my tags and albums, but no
thumbnails (kioslave is working of course). Switching between tags, date and
album view doesn't help. Also scanning for new images is not bringing back
the thumbnails. I had to restart.

After that, thumbnails are visible, BUT: Clicking on them will not display
anything. I have to resize the splitter again to see anything.
I would say something goes wrong here while converting, would make sense, but
why can't I see thumbnails on first start?

I have turned on the displaying of the total numbers of images in a folder,
every folder has a (0) label beside itself. This means that the images are
not recognized at all, it is not just a displaying problem.

So actually two of our most annoying bugs are still present: No images on
first start (after conversion) and the splitter bug (DAMN YOU SPLITTER :-))

Andi

On Monday 01 December 2008 21:41:44 Andi Clemens wrote:
> Somehow I'm not sure if it really fixes the splitter problems... I had the
> issue just 2 minutes ago... AGAIN!
> Now I don't know if I had messed up my digikamrc file or if it is the same
> old bug we are hunting for moths now.
>
> I will not commit it and test it a little more. Next I will convert from
> KDE3 to KDE4, it should fail then...
> I will keep you informed.
>
> Andi
>
> On Monday 01 December 2008 21:21:50 Andi Clemens wrote:
> > On Monday 01 December 2008 21:13:38 Marcel Wiesweg wrote:
> > > > Marcel, any comment on why we use toBase64() methods to save splitter
> > > > state? Otherwise I will commit the changes to SVN, for me it works
> > > > fine in my GIT repo, even with "broken" digikamrc files.
> > > >
> > > > Andi
> > >
> > > We get raw binary data from QSplitter, and use toBase64 to encode it to
> > > ASCII to store it in the config file. We use toBase64 before we store
> > > to KConfig and use fromBase64 after reading from KConfig.
> > > I dont know any more where we took that from or if I made this up
> > > myself, and I dont know if this is strictly necessary. Possibly KConfig
> > > can perfectly well store raw binary data.
> > > If you can confirm that bugs are caused by this and after removal the
> > > problems are solved, and configuration is always saved, then please
> > > commit. (Keep in mind that when you remove fromBase64 the "broken"
> > > digikamrc files will fail to load at all.)
> >
> > No, they load perfectly... I assume that the SplitterState config vars
> > will not be read at all (because they are unknown now) and the default
> > values will be used. After closing digiKam, the new SplitterState will be
> > saved.
> >
> > OK I will commit it then...
> >
> > Andi
> >
> > > 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

_______________________________________________
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

On Tuesday 02 December 2008 12:17:07 Gilles Caulier wrote:

> Andi,
>
> Undependetly of spliter size bug, i cannot find an fine explication why the
> image is not displayed in case of splitter size is null (thumbbar not
> visible).
>
> This is not logic to not show preview image here. I suspect that zoom level
> (from status bar) has an invalid value at first init. later, it is relevant
> of preview widget size to be initialized properly (when splitter is
> resized).
>
> To resume my idea, i suspect a race condition between zoom level and
> preview widget/Splitter/thumbbar are displayed (initialized).
>
> Can you feel my viewpoint ?

I can "feel" you ... ;-)

This is what I was silently thinking, too. It doesn't make sense that you
can't see the preview, only because the splitter is minimzed.
So it might be a size problem of the preview image.

And what about the empty folders / albums / tags when importing KDE3 database?

Marcel,
any idea?

Andi

>
> Gilles
>
> 2008/12/2 Andi Clemens <[hidden email]>
>
> > Bad news :-(
> > This patch doesn't help, and some of our old bugs are still available,
> > too.
> >
> > I copied my KDE3 rc file into the KDE4 folder and let digikam convert the
> > database and the rc file (with and without this patch).
> >
> > After the conversion was finished, I could see my tags and albums, but no
> > thumbnails (kioslave is working of course). Switching between tags, date
> > and
> > album view doesn't help. Also scanning for new images is not bringing
> > back the thumbnails. I had to restart.
> >
> > After that, thumbnails are visible, BUT: Clicking on them will not
> > display anything. I have to resize the splitter again to see anything.
> > I would say something goes wrong here while converting, would make sense,
> > but
> > why can't I see thumbnails on first start?
> >
> > I have turned on the displaying of the total numbers of images in a
> > folder, every folder has a (0) label beside itself. This means that the
> > images are not recognized at all, it is not just a displaying problem.
> >
> > So actually two of our most annoying bugs are still present: No images on
> > first start (after conversion) and the splitter bug (DAMN YOU SPLITTER
> > :-))
> >
> > Andi
> >
> > On Monday 01 December 2008 21:41:44 Andi Clemens wrote:
> > > Somehow I'm not sure if it really fixes the splitter problems... I had
> >
> > the
> >
> > > issue just 2 minutes ago... AGAIN!
> > > Now I don't know if I had messed up my digikamrc file or if it is the
> >
> > same
> >
> > > old bug we are hunting for moths now.
> > >
> > > I will not commit it and test it a little more. Next I will convert
> > > from KDE3 to KDE4, it should fail then...
> > > I will keep you informed.
> > >
> > > Andi
> > >
> > > On Monday 01 December 2008 21:21:50 Andi Clemens wrote:
> > > > On Monday 01 December 2008 21:13:38 Marcel Wiesweg wrote:
> > > > > > Marcel, any comment on why we use toBase64() methods to save
> >
> > splitter
> >
> > > > > > state? Otherwise I will commit the changes to SVN, for me it
> > > > > > works fine in my GIT repo, even with "broken" digikamrc files.
> > > > > >
> > > > > > Andi
> > > > >
> > > > > We get raw binary data from QSplitter, and use toBase64 to encode
> > > > > it
> >
> > to
> >
> > > > > ASCII to store it in the config file. We use toBase64 before we
> > > > > store to KConfig and use fromBase64 after reading from KConfig.
> > > > > I dont know any more where we took that from or if I made this up
> > > > > myself, and I dont know if this is strictly necessary. Possibly
> >
> > KConfig
> >
> > > > > can perfectly well store raw binary data.
> > > > > If you can confirm that bugs are caused by this and after removal
> > > > > the problems are solved, and configuration is always saved, then
> > > > > please commit. (Keep in mind that when you remove fromBase64 the
> > > > > "broken" digikamrc files will fail to load at all.)
> > > >
> > > > No, they load perfectly... I assume that the SplitterState config
> > > > vars will not be read at all (because they are unknown now) and the
> > > > default values will be used. After closing digiKam, the new
> > > > SplitterState will
> >
> > be
> >
> > > > saved.
> > > >
> > > > OK I will commit it then...
> > > >
> > > > Andi
> > > >
> > > > > 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
> >
> > _______________________________________________
> > 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

Hi,

I've done some debugging with the broken splitter, and as you can see in the
attached screenshot, the ImagePreviewWidget is way to small (negative
height). But why?
Where does this come from?

Andi

On Tuesday 02 December 2008 12:24:05 Andi Clemens wrote:

> On Tuesday 02 December 2008 12:17:07 Gilles Caulier wrote:
> > Andi,
> >
> > Undependetly of spliter size bug, i cannot find an fine explication why
> > the image is not displayed in case of splitter size is null (thumbbar not
> > visible).
> >
> > This is not logic to not show preview image here. I suspect that zoom
> > level (from status bar) has an invalid value at first init. later, it is
> > relevant of preview widget size to be initialized properly (when splitter
> > is resized).
> >
> > To resume my idea, i suspect a race condition between zoom level and
> > preview widget/Splitter/thumbbar are displayed (initialized).
> >
> > Can you feel my viewpoint ?
>
> I can "feel" you ... ;-)
>
> This is what I was silently thinking, too. It doesn't make sense that you
> can't see the preview, only because the splitter is minimzed.
> So it might be a size problem of the preview image.
>
> And what about the empty folders / albums / tags when importing KDE3
> database?
>
> Marcel,
> any idea?
>
> Andi
>
> > Gilles
> >
> > 2008/12/2 Andi Clemens <[hidden email]>
> >
> > > Bad news :-(
> > > This patch doesn't help, and some of our old bugs are still available,
> > > too.
> > >
> > > I copied my KDE3 rc file into the KDE4 folder and let digikam convert
> > > the database and the rc file (with and without this patch).
> > >
> > > After the conversion was finished, I could see my tags and albums, but
> > > no thumbnails (kioslave is working of course). Switching between tags,
> > > date and
> > > album view doesn't help. Also scanning for new images is not bringing
> > > back the thumbnails. I had to restart.
> > >
> > > After that, thumbnails are visible, BUT: Clicking on them will not
> > > display anything. I have to resize the splitter again to see anything.
> > > I would say something goes wrong here while converting, would make
> > > sense, but
> > > why can't I see thumbnails on first start?
> > >
> > > I have turned on the displaying of the total numbers of images in a
> > > folder, every folder has a (0) label beside itself. This means that the
> > > images are not recognized at all, it is not just a displaying problem.
> > >
> > > So actually two of our most annoying bugs are still present: No images
> > > on first start (after conversion) and the splitter bug (DAMN YOU
> > > SPLITTER
> > >
> > > :-))
> > >
> > > Andi
> > >
> > > On Monday 01 December 2008 21:41:44 Andi Clemens wrote:
> > > > Somehow I'm not sure if it really fixes the splitter problems... I
> > > > had
> > >
> > > the
> > >
> > > > issue just 2 minutes ago... AGAIN!
> > > > Now I don't know if I had messed up my digikamrc file or if it is the
> > >
> > > same
> > >
> > > > old bug we are hunting for moths now.
> > > >
> > > > I will not commit it and test it a little more. Next I will convert
> > > > from KDE3 to KDE4, it should fail then...
> > > > I will keep you informed.
> > > >
> > > > Andi
> > > >
> > > > On Monday 01 December 2008 21:21:50 Andi Clemens wrote:
> > > > > On Monday 01 December 2008 21:13:38 Marcel Wiesweg wrote:
> > > > > > > Marcel, any comment on why we use toBase64() methods to save
> > >
> > > splitter
> > >
> > > > > > > state? Otherwise I will commit the changes to SVN, for me it
> > > > > > > works fine in my GIT repo, even with "broken" digikamrc files.
> > > > > > >
> > > > > > > Andi
> > > > > >
> > > > > > We get raw binary data from QSplitter, and use toBase64 to encode
> > > > > > it
> > >
> > > to
> > >
> > > > > > ASCII to store it in the config file. We use toBase64 before we
> > > > > > store to KConfig and use fromBase64 after reading from KConfig.
> > > > > > I dont know any more where we took that from or if I made this up
> > > > > > myself, and I dont know if this is strictly necessary. Possibly
> > >
> > > KConfig
> > >
> > > > > > can perfectly well store raw binary data.
> > > > > > If you can confirm that bugs are caused by this and after removal
> > > > > > the problems are solved, and configuration is always saved, then
> > > > > > please commit. (Keep in mind that when you remove fromBase64 the
> > > > > > "broken" digikamrc files will fail to load at all.)
> > > > >
> > > > > No, they load perfectly... I assume that the SplitterState config
> > > > > vars will not be read at all (because they are unknown now) and the
> > > > > default values will be used. After closing digiKam, the new
> > > > > SplitterState will
> > >
> > > be
> > >
> > > > > saved.
> > > > >
> > > > > OK I will commit it then...
> > > > >
> > > > > Andi
> > > > >
> > > > > > 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
> > >
> > > _______________________________________________
> > > 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

[Gilles Caulier-4]

2008/12/3 Andi Clemens <[hidden email]>

Hi,

I've done some debugging with the broken splitter, and as you can see in the
attached screenshot, the ImagePreviewWidget is way to small (negative
height). But why?
Where does this come from?

It's normal if dstHeight=-6...

... but wait. Using PreviewWidget::contentsRect() is valid with KDE4 port ?

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel