Version: 0.9.3 (using 3.5.9 "release 49.1" , openSUSE 11.0) Compiler: Target: x86_64-suse-linux OS: Linux (x86_64) release 2.6.25.11-0.1-default Digikam has a settings dialog, and the camera GUI has settings too (in tabs on the side). This is confusing. Therefore I propose to duplicate the settings of the camera GUI and to put them into Digikam's settings dialog too. This way one could go through the settings dialog and discover all of the program's settings without much seaching. A natural place would be the list of cameras. Each camera should have a configuration button. Clicking the button would show a camera settings dialog with the settings widget from the camera GUI. As the camera GUI is not used as an independent program, the natural place for its settings should be Digicam's settings dialog. Duplicating the camera settings and making them accessible from both the general configuration and the camera GUI, is a good idea because people have different usage patterns. In my specific case I wanted to switch on "Autocreation of Albums". It had become switched off after I upgraded the operation system. I searched for this setting only in Digicam's settings dialog for a long time. I did not think that the camera GUI had own settings because I use the camera GUI as a simple dialog for downloading images.
What about this one? Gilles, Marcel, Arnd, what do you think? Andi
To get camera config from libgphoto2, we need to wait a better and universal) way from libgphoto2 to make config layout and widget list. The current one is oriented on GTK stuff (using GTK loop if i remember) and it's the hell to setup signal/slot connections. I have already tried to make a camera config dialog but it's cannot be completed as well. Loook in cameragui/gpconfigdlg.cpp I don't know if libgphoto2 will use a new method to get camera config. Something based on XML will be nice. Marcus, any news about it ? Gilles Caulier
There is absolutely nothing GTK related in libgphoto2 since forever. ;) The configuration uses an abstract widget tree, which can be rendered any way you want. Check out the kdegraphics4/kamera/kcontrol/ configuration dialog in kameraconfigdialog.cpp. Perhaps we could even launch that module there in some way. However I do not really see the usefulness... ALmost modern cameras do not need to be configured for the usage pattern of digikam. "Autocreation of Albums" is not a gphoto settings, but a digikam setting I think.
Maybe Gilles was thinking about glib event loop? That is/was problem for Qt3 but Qt4 uses it, so for >= 0.10 shouldn't create problems.
I think the original report is about the download settings in the camera dialog, that is Jpeg rotate, rename by date, auto create albums etc. This is purely digikam code. Eike has two wishes as I understand that: 1) He want to have these settings in the main configuration dialog 2) He wants to store these settings per-camera and not globally For 1) I would vote for wontfix, because there is a certain movement to go away from enormous configuration dialog and make more options directly accessible where it is needed. 2) is a wish but currently I dont believe it is worth the effort.
1/ Agree : won't fix. 2/ i'm not sure. It's possible to store configuration by Camera using digiKam xml file. Any others viewpoints here ? Gilles Caulier
Andi, About point 1/, i agree with Marcel : Won't fix. What do you think about point 2/ ? Gilles Caulier
1. Yes, I would also vote "wontfix", because our settings dialog is already MUCH too crowded. 2. If it is easy to implement with XML files, I would say yes. I also have two cameras, but I don't see the point in having multiple configuration here, at least for my workflow. But it could work somehow like this: a) camera not detected: load default.xml when CameraUI is opened, on close ask if you want to save the settings in a new config file b) camera detected: open and save in the appropriate xml file But there is a problem: You can also import from folders. We don't want to use custom settings for this, too. So the question is: is it easy or time-consuming to implement? We have already so much to do, maybe this is just not worth it? And: do most users really need this? Andi
Is this still valid nowadays?