twilly
GUI
odvr should include a basic GUI.
Original issue reported on code.google.com by [email protected] on 27 Oct 2007 at 5:49
A GUI would be nice, but the priority definitely shouldn't be medium. I would
think
fuse would be more important.
Original comment by [email protected] on 10 Jan 2008 at 12:21
I think this program is quite confusing for newbies without a GUI...
Original comment by [email protected] on 8 Mar 2008 at 6:47
There's no need for a gui at this point. I would think the more pressing issue
is
support for all of the recording file formats.
Original comment by [email protected] on 9 Mar 2008 at 4:17
If nobody has already started working on a GUI, I would like to use it as an
exercise
to learn a bit about GTK+.
Original comment by [email protected] on 1 Apr 2008 at 6:04
I haven't started working on a GUI yet (life and getting other important bugs
fixed
comes first). I'll put just about anything in the tarball that's reasonable for
a
GUI, but it has to work :P. It doesn't even have to be in C or GTK+ (Python,
Ruby,
Qt, etc).
Original comment by [email protected] on 2 Apr 2008 at 3:14
How do i use this? .. i type "odvr" when I'm connected to my vn-4100pc, and it
just
shows the model number. How do I tell it to transfer the files? There is no
manual
page. Please help.
darren@ubuntu:~$ odvr
Model: 4100PC
Original comment by [email protected] on 14 Apr 2008 at 2:16
In implementing a gui for this, I will be linking with olympusdrv.c so that I
don't
need to re-invent that wheel and hopefully get the benefit of any changes made
to it.
The decision I need to make soon is whether the gui should be a separate
executable
or should be an extension of the existing cli.
If extending the cli to start the gui, I would propose two separate methods to
start
the gui rather than the cli:
1) If odvr is atarted in the background start the gui.
2) If odvr is atarted with a new cli option (suggestions ?) then start the gui.
I see advantages and disadvantages with a the two approaches:
Separate cli and gui:
+ Smaller executable for cli.
+ Any changes to olympusdrv can be done in isolation from gui. New cli can be
released with gui following afterwards. Changes to olympusdrv may stop gui from
building, but cli is not affected.
Integrated cli and gui:
+ One executable - hopefully less confusion for users.
- cli and gui need to stay in sync if any changes are made to olympusdrv.c
- One executable requires gtk libraries, even if the gui is not being used.
Any thoughts on which option I should go for?
Original comment by [email protected] on 16 Apr 2008 at 1:28
I'm no developer, but I think separate could be better since it's easier to
develop
the core. That way, Tristan can update the main code, you can develop the GUI,
and if
someone else wants to make another GUI (like a Qt one for us KDE users) it
would be easy.
Besides, then I can poke around in the GUI and try to pick up some basic GUI
programming, something I've been wanting to do for a long time ;-)
Either way, make sure you email me or post something in ticket 8 so I can make
a .deb
for you.
Original comment by [email protected] on 16 Apr 2008 at 2:09
I wouldn't go with the start-the-gui-if-backgrounded technique because it
wouldn't
surprise me if someone has scripted the CLI version, which may background the
CLI.
Changing this will break these scripts and isn't expected *NIX behavior.
Although I don't mind if it were the case, I do not recommend integration of
the GUI
and CLI together. Reason being is that I want to encourage different GUIs
depending
on user taste, say a Gnome native and a KDE native or a GUI written in Python.
Separation of the CLI and GUI will make alternative GUI support easier in the
future.
IMHO, it'll also keep the CLI and GUI code cleaner since there's less
interaction.
As far as breaking builds go, I don't intend on making releases with a broken
GUI.
API changes should be assumed to break all builds and hopefully that'll be a
deterrent to make small incompatible API changes. The odvr code is only ~1200
lines
big anyway, so maintenance shouldn't be much of an issue.
Original comment by [email protected] on 16 Apr 2008 at 4:02
I had been tending towards the separate gui myself. Your comments help to
clarify the
thinking. The development that I have done so far had the gui separate so I
will
just continue on that route.
Thanks,
Conor
Original comment by [email protected] on 16 Apr 2008 at 5:21
I have attached a tarfile which includes a gui. It still needs some cleanup and
extra work, but the basic functions are there. I have included everything from
0.1.4.1 in the tarfile even if there are no changes to some files.
I used this as an exercise for myself to get some familiarity with GTK. I may
not
have used the best widgets for the various jobs. I welcome any pointers where
things
could be improved.
I have made minor change to odvrdrv.h:
* Add ODVR_FOLDER_S - Nothing uses this, but included for completeness.
Perhaps it
might be better to remove all except ODVR_FOLDER_A instead, which is the only
one used.
* Changed ODVR_NUM_FOLDERS from 5 to 4 - The change from 0.1.4 to 0.1.4.1 no
longer
needed 5 folders.
* Added ODVR_QUALITY_NUM - I use this in the gui when selecting by quality.
Considerable changes to Makefile. I have not yet included a rule for an
odvrgui.x86.
New files: gui.c, odvr_date.[ch], odvr_gui.[ch] icons/*.png icons/*.xcf
Work that I plan to complete:
* General cleanup
* Check for and fix memory leaks
* When clearing a folder, remove the files from the view.
* Add help->about
* Add select->by date
* Add configuration file. Save settings (destination directory, etc) between
sessions.
* Improve the progress bar. At present this is based only on the number of
files, not
on the size of the files. The granularity could be improved by hooking into the
olympusdrv.c, but I don't want to effect the cli code.
* Sort files in folders by length, date, and quality.
* Configure different date formats.
* Add a Makefile rule for odvrgui.x86.
* Search alternative directories for icons. Currently icons should be in
/usr/local/icons. If they are not installed, the gui will only run if you
start it
in the icon directory.
Any other suggestions for improvements are welcome.
There are some things that I have not been able to test. The options for
folder D
and S should only appear when the relevent model is attached. I have tested it
with
4100PC.
Original comment by [email protected] on 18 Apr 2008 at 10:58
Attachments:
Not too shabby for an early attempt, and that was super-fast turnaround. There
does
exist several usability issues, but so far so good. I'll take a look into
replaying
my SVN setup here onto Google Code and give you commit access. I've been
meaning to
use Google's SVN anyway...
As a side note, I suggest the name 'odvr-gui' instead of 'odvrgui' because I
think
it's clearer and follows similar conventions (gnome-*, gtk-*, system-config-*,
git-gui, etc).
Original comment by [email protected] on 18 Apr 2008 at 11:58
What do you think (apart from name change from 'odvrgui' to 'odvr-gui') should
be top
priorities before it should be considered a release candidate?
Original comment by [email protected] on 19 Apr 2008 at 11:40
Things like 'odvr-gui' as the name, correct path handling with icons, and
perhaps a
configure script?
Original comment by [email protected] on 19 Apr 2008 at 11:55
New tarfile attached. I have made a number of changes.
* Added a function odvr_wavfilesize to olympusdrv. This returns an
approximate size
of the wav file that will be generated. I use this so I can display the
progress of
each file.
* Added a configuration file. This saves some settings between sessions. If
any of
the settings has changed they will be saved when you exit using the file->quit
menu.
They will not be saved if the program is terminated in any other way.
* Icons are now embedded in the executable.
* Dialog added to help->about menu
The multipliers that I have used for estimating the wav file size has only been
tested for XHQ on 4100PC. I have put multipliers for the other quality
settings but
they are unlikely to be cortrect. When the multipliers are incorrect, it will
result
in the progress bar either not reaching 100% or hitting 100% before the file
transfer
is complete. To help in tuning the multiplier value, you can see the
calculated
file size in the window if you edit the configuration file ~/.odvr-gui.cfg and
change
the setting for show_wav_file_size from 0 to 1.
Original comment by [email protected] on 22 Apr 2008 at 6:09
Attachments:
New tarfile with the following changes from 20080422:
* Some code cleanup.
* Date format can be set in the config file. See strftime man page for format.
* Keep original timestamp on downloaded files if config option
keep_original_timestamp is set.
* Improved progress bar. If config option report_total_filesize is set, the
total
file size for all selected files is calculated before transfer is started and
used to
set the percentage on the upper progress bar. If the option is not set, the
progress
bar jumps as each file is completed.
Note: The configuration file ~/.odvr-gui.cfg is created and updated when exiting
using file->quit if any configuration settings are changed. The simplest way to
force this file to be created is to resize the window then file->quit.
The configuration file looks like:
# Configuration file for odvr-gui
version:0.1.4.1-cml
destination_dir:/home/cml/Desktop
show_wav_file_size:0
keep_original_timestamp:1
window_width:500
window_height:654
progress_window_width:500
progress_window_height:126
date_format:%d/%b/%y
report_total_filesize:1
version is not used but may be useful in the future.
destination_dir is the target directory for the wav files.
show_wav_file_size, if set to 1 shows an additional column with the estimated
size of
the wav file that would be created. This may be useful for calibrating the
multipliers in odvr_wavfilesize.
keep_original_timestamp, if set, makes the creation and modified timestamp of
the
wave file to be the same as the time and date from the device.
window_width, window_height sets the size of the main window.
progress_window, progress_window_height set the size of the progress window as
files
are being transferred.
date_format configures how the date will be displayed. The format of the time
is not
configurable. The following format fields are used:
%y - Year, example 08
%Y - Year, example 2008
%b - Month, example Apr
%B - Month, example April
%m - Month, example 04
%d - Day, example 03
%e - Day, example 3
Example %d/%b/%y gives 24/Apr/08. The default %Y/%m/%d gives 2008/04/24.
Original comment by [email protected] on 24 Apr 2008 at 10:31
Attachments:
Whoa, a lot of code there :). I better re-email Google so I can put SVN up
here. Then
we can import your gui code and make a release :).
Original comment by [email protected] on 24 Apr 2008 at 11:30
Tristan and Conor, just let me when you want a .deb of this.
Original comment by [email protected] on 25 Apr 2008 at 1:17
Regarding a .deb
1) Can we automate it? I can help with the makefile if necessary.
2) I assume that we want to package odvr and odvr-gui separately. If we put
them
both in the same package then we have the issue that odvr-gui depends on many
more
libraries that odvr does not.
Original comment by [email protected] on 25 Apr 2008 at 2:35
I've already got it somewhat automated for my build, but I only build against my
architecture (amd64). Perhaps it's time to figure out how to get a build
automated
and doing cross compiles.
Original comment by [email protected] on 25 Apr 2008 at 5:19
I gave up trying to replicate subversion history into Google's repository. It's
just
too darn difficult (Subversion really wasn't crated with this operation in mind,
that's for sure).
I've added you as a project member, conor. Go ahead and try to checkin your GUI
stuff.
Original comment by [email protected] on 5 May 2008 at 9:25
Code submitted. I think I checked in everything, but let me know if I missed
something and I will correct it tomorrow. (Logging off now as it is just after
midnight here).
Original comment by [email protected] on 5 May 2008 at 11:05
Thank you soo much!!!! I can now remove the win partition on my laptop!!
about the gui:
1)could you add a "clear all"?
2)after i removed the files the list window is not updated (update button
maybe?)
Thank you once again!!
Original comment by [email protected] on 22 Jul 2008 at 7:56
Hi,
I have an Olympus w-10 recorder/camera. I compiled odvr but unfortunately it
doesn't
seem to support my unit. What are the chances that we will have the
capabilities of
operating the w-10 with this software? Thanks in advance.
Daniel
Original comment by [email protected] on 3 Dec 2008 at 7:01
Why not using the GUI of Olympus itself with wine?
I have tried to install it and I do get the interface correctly via wine.
It only doesn't functionate, if I plug in the recorder all functions for
downloading
and so stay blank, I can't use it.
If that can be fixed you can have a great solution.
Jacques
Original comment by [email protected] on 13 Dec 2008 at 3:30
I'm just a journalist who love linux like a normal user, i think the GUI is
very
important I'm so newbie i don't know almost nothing of terminal.
and how say the comment 28 "Why not using the GUI of Olympus itself with wine?"
and thanks your works is Amazing!
Original comment by [email protected] on 10 Nov 2009 at 2:36
Apart from being nice, it would be much more easy and quick to work with recorded files (I use Olympus DVRs for my university lessons); yes, first of all, all previous bugs should be fixed…
