[Digikam-devel] extragear/graphics/digikam

[Gilles Caulier]

Le Mardi 17 Janvier 2006 19:58, vous avez écrit :
> > ImageWindowSavingContext will be common to showfoto and IE. To do a clean
> > implementation, I recommend you to put ImageWindowSavingContext class
> > implementation to a separate header file, like iofilesettingscontainer
> > class.
> >
> > Maintening showfoto and IE GUI implementation is infernal. I don't know
> > why Renchi haven't created a common class for that. There are a lot of
> > common code in both.
> >
> > We need talking about this point for the future... Joern, Tom, what's do
> > you think about ?
>
> YES, please!
>
> :-)

No response. I will trying to contact Tom and Joern by IRC.

About IRC, have you trying #digikam channel :

http://www.digikam.org/?q=contact

>
> The common code probably increased a lot with the addition of right side
> bar and thumb bar. The current state is unmaintainable. Things happen like
> ImageWindow using KTempFile, while Showfoto creates its own file name. So
> - canvas
> - right side bar
> - thumb bar
> - loading and saving
> and a lot of other stuff can be done in a common class.
>
> Some other things like managing the list of URLs, the current picture are
> specific, but this seems to be a small subset. However, I am not familiar
> with any pitfalls in this code, both files are large, complex and not easy
> to get a complete view of.
>

I'm completly agree with you. I will take a look to create a comon GUI class 
for IE and showfoto. Until this new class will be created, we need to 
continue with the curren timplementation.

> > > I just split the function in two parts and made the local variables
> > > which are used in the second part member variables. In ImageWindow and
> > > Showfoto, where there are more than one such variable, I introduced a
> > > class which bundles them to keep things clear. Neither the naming of
> > > these variables nor the functions as such have been changed.
> > >
> > > >    - put in hooks for progress info display
> > > >    - added preliminary code to wait on asynchronous saving, needed
> > > > for promptUserSave() - added a modal progress dialog
> > > >        - needs to be tested and fixed, see TODO below
> >
> > ok. I will test it indeep...
> >
> > something is broken in current implementation about saving : the result
> > file still with the temporary file name, not the target filename.
> >
> > > This is a problem I had not thought of. In promptUserSave(), a return
> > > value is needed from the save() functions. As far as I see, at least
> > > when promptUserSave is called from closeEvent(), this cannot be
> > > avoided. So we need to wait in this function till slotSavingFinished is
> > > called, essentially this means waiting for event delivery in the event
> > > queue.
> > >
> > > My Qt experience ends here, I am lacking a deeper understanding for
> > > things like enter_loop, qt_enter_modal, modal dialogs and such. I just
> > > put in a modal dialog which is closed in finishSaving in the hope that
> > > this works, but this needs testing.
> > >
> > > It is probably better to use the standard, still-to-be-written progress
> > > display and use some other means for synchronizing, something like
> > > Digikam SyncJob?
> >
> > ... I haven't yet study SyncJob implementation. I will take a look.
>
> There is a dummy widget created and some magic is done with qt_enter_loop.
> As I said, I have no experience of this, and there is no documentation.
>

I need any time to study this implementation (:=)))
-- 
Gilles