[Bitpim-devel] updates and build preparation

Post by Roger Binns
I can't seem to find any problems with it, which means
you will take at most ten seconds.

You were right. Perhaps nine seconds . :-)

Very strange Mac behavior. Ringtone tab seems OK. But Wallpaper tab
produced repeated exceptions when attempting to use scroll bar. It took
me a while to grab one because I had a problem resizing the exception
window to see the text. - Vic

An unexpected exception has occurred.
Please see the help for details on what to do.

Traceback (most recent call last):
File "/Users/vic/Projects/bitpim/guiwidgets.py", line 1089, in
OnTooltipTimer
res=self.aggdisp.HitTest(x,y)
File "/Users/vic/Projects/bitpim/aggregatedisplay.py", line 309, in
HitTest
startx+=self.boundingboxes[i][num][0]
TypeError: unsubscriptable object

Variables by last 8 frames, innermost last

Frame ? in /Users/vic/Projects/bitpim/bp.py at line 79
profile = <function profile at 0x10f4f0>
__file__ = '/Users/vic/Projects/bitpim/bp.py'
__name__ = '__main__'
__doc__ = 'Main entry point to Bitpim\n\nIt invokes BitPim in
gui or commandline mode as a

Frame run in /Users/vic/Projects/bitpim/gui.py at line 361
args = (['/Users/vic/Projects/bitpim/bp.py'],)
m = <gui.MainApp; proxy of C++ wxPyApp instance at
_0233c600_p_wxPyApp>

Frame MainLoop in
//Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-
packages/wx/_core.py at line 5262
self = <gui.MainApp; proxy of C++ wxPyApp instance at
_0233c600_p_wxPyApp>

Frame MainLoop in
//Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-
packages/wx/_core.py at line 4732
args = (<gui.MainApp; proxy of C++ wxPyApp instance at
_0233c600_p_wxPyApp>,)
kwargs = Keys []
{}

Frame OnTooltipTimer in /Users/vic/Projects/bitpim/guiwidgets.py at
line 1089
y = 1525
x = 228
self = <wallpaper.WallpaperView; proxy of C++ wxPanel
instance at _03773220_p_wxPanel>
_ = <wx._misc.TimerEvent; proxy of C++ wxTimerEvent
instance at _bfffe580_p_wxTimerE

Frame HitTest in /Users/vic/Projects/bitpim/aggregatedisplay.py at line
309
origin = 1341
startx = 3
i = 1
section = <aggregatedisplay.SectionHeader object at 0x1e51d70>
cury = 1446
pointy = 1525
item = <wallpaper.DisplayItem object at 0x1e51ed0>
num = 0
pointx = 228
posy = 1446
y = 0
x = 0
extrawidth = 6
self = <aggregatedisplay.Display; proxy of C++
wxScrolledWindow instance at _037736c0_p

Roger Binns

2005-01-04 17:11:14 UTC

Post by Vic Heintz
Very strange Mac behavior. Ringtone tab seems OK. But Wallpaper tab
produced repeated exceptions when attempting to use scroll bar. It took
me a while to grab one because I had a problem resizing the exception
window to see the text. - Vic

In this case the issue is happening because your cursor is resting over
an item on screen that hasn't been drawn ever. I am very curious as
to how exactly you can do that.

Can you try changing VSCROLLPIXELS in aggregatedisplay.py:57 to
one and see if that has any effect.

You can turn off the tooltip code by always returning without starting
the timer in OnMouseEvent in guiwidgets.py:1079

Post by Vic Heintz
File "/Users/vic/Projects/bitpim/aggregatedisplay.py", line 309, in
HitTest
startx+=self.boundingboxes[i][num][0]
TypeError: unsubscriptable object

Please print out what self.boundingboxes[i][num][0] is at that point.
I think it will be None, with any other value being a serious flaw.
I have just put in defensive coding in to cope with None at that point,
although it should never happen. (It is only None if the item
has never been drawn on the screen.)

Roger

Vic Heintz

2005-01-04 13:16:58 UTC

Post by Vic Heintz
Very strange Mac behavior. Ringtone tab seems OK.

I take that back, partially. The Ringers tab is better for me in Mac OS
Jaguar than it was with the old implementation because it arranges the
items in rows now rather than a single vertical column. The font is
almost too small to read, however. It looks to be about 6 pt. I think
if I didn't already know what they were called I wouldn't be able to
make out the ringtone names.

Also, I have seen stranger things with wxPython in Jaguar, but as I
resize the window larger, at some point the vertical scroll bar goes
away and is replaced by a horizontal one. If I use this scroll bar,
everything disappears: all ringer icons AND the horizontal scrollbar.
The only way to get everything back is to drag the window corner to
resize. I don't think the scrollbar actually belongs to the ringer
window. If I quit BitPim and rerun it using the ringer tab before any
operations in wallpaper, I don't see the horizontal scrollbar. I think
it is somehow a remnant of the exception window that was never quite
properly displayed before.

Good news is that unlike the wallpaper tab, none of these redraw
operations has produced an exception.

Vic

Roger Binns

2005-01-04 16:33:02 UTC

The font is almost too small to read, however. It looks to be about 6 pt.

It is 8 pt:

f1=wx.TheFontList.FindOrCreateFont(8, wx.SWISS, wx.NORMAL, wx.BOLD)
f2=wx.TheFontList.FindOrCreateFont(8, wx.SWISS, wx.NORMAL, wx.NORMAL)

Do Macs have their screen dpi set up wrong? Please work out a size that
does work (those lines are in guiwdgets.py:1007) and I'll use a different
point size for Mac.

resize the window larger, at some point the vertical scroll bar goes
away and is replaced by a horizontal one.

Errr, that is impossible. I explicitly request only the vertical scrollbar
and set the the horizontal scrollbar off. Line 340 of aggregatedisplay.py:

self.SetScrollbars(0,1,0,self.vheight,0, self.GetViewStart()[1])
self.SetScrollRate(0, self.VSCROLLPIXELS)

Roger

Steven Palm

2005-01-04 16:53:40 UTC

The font is almost too small to read, however. It looks to be about 6 pt.

f1=wx.TheFontList.FindOrCreateFont(8, wx.SWISS, wx.NORMAL, wx.BOLD)
f2=wx.TheFontList.FindOrCreateFont(8, wx.SWISS, wx.NORMAL,
wx.NORMAL)
Do Macs have their screen dpi set up wrong?

Or is it the rest of the world? :-) I believe they have always used
72dpi for screen rendering, whereas I think the Windows and perhaps
Linux world have used 96dpi. I could be wrong on the Windows side, I
haven't used it in forever, but I know that typically Windows desgined
web pages tend to render smaller on the Mac because of this.

Post by Roger Binns
Please work out a size that does work (those lines are in
guiwdgets.py:1007) and I'll use a different point size for Mac.

Will do. Here's a snapshot just so you know what it's like now,
mostly as FYI.

Resize the window larger, at some point the vertical scroll bar goes
away and is replaced by a horizontal one.

Errr, that is impossible. I explicitly request only the vertical scrollbar
and set the the horizontal scrollbar off. Line 340 of

I don't see this here at all, and it works fine... The initial load of
the Wallpaper images is excruciatingly slow for the few images that I
have, but once they load I can scroll up and down the whole view
without much problem. If I select refresh from the pop-up menu, it is
slow going again until they all reload, and then it speeds up again.

Roger Binns

2005-01-04 17:22:28 UTC

Post by Steven Palm
Or is it the rest of the world? :-) I believe they have always used
72dpi for screen rendering, whereas I think the Windows and perhaps
Linux world have used 96dpi. I could be wrong on the Windows side, I
haven't used it in forever, but I know that typically Windows desgined
web pages tend to render smaller on the Mac because of this.

Windows designed web pages render smaller everywhere including on my
Windows machine because of people hard coding absolute sizes. It
is one thing that really winds me up.

My Windows box is currently at 96dpi and my Linux box is 101 dpi.
The latter reads the information from the monitor. So they could both
be wrong and Mac be right, or the other way round. And then of course
maybe Mac inches are shorter due to Job's distortion field :-)

Post by Steven Palm
Will do. Here's a snapshot just so you know what it's like now,
mostly as FYI.

Windows one attached.

Post by Steven Palm
I don't see this here at all, and it works fine... The initial load of
the Wallpaper images is excruciatingly slow for the few images that I
have, but once they load I can scroll up and down the whole view
without much problem. If I select refresh from the pop-up menu, it is
slow going again until they all reload, and then it speeds up again.

Mmmmm. It would seem that memory device context drawing is very slow
on wxMac as well as image loading. I will be making one change this evening
that will speed things up a bit. The images are all reloaded for any
change to the data such as adding or removing anything. If it gets
real bad I'll have to have some sort of caching scheme. (The previous
code had that and it was a pain to change the internals because of
all the 'optimisations'.)

Roger

Vic Heintz

2005-01-04 21:16:50 UTC

File "/Users/vic/Projects/bitpim/aggregatedisplay.py", line 401, in
Draw
dc.DrawText(self.label, xoff+3, yoff)
File
"//Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/
site- packages/wx/_gdi.py", line 2748, in DrawText
return _gdi_.DC_DrawText(*args, **kwargs)
TypeError: String or Unicode type required

self.label can only ever be a string (non-Unicode). You'll need to
get into
the debugger and try to figure out what on earth you are getting.

The problem seems to be the label for the second grouping of images.
The first grouping has the label "BMP" and consists of the images that
were loaded via bitpim into the wallpaper tab. As soon as I scroll down
to the point where the next label should first be drawn, an exception
is thrown. I can somehow manage to scroll to the bottom after getting
several exceptions. I can then start scrolling back up but when I get
to the point where the label for my camera pictures group should be
drawn, I get the exception again. One thing that is quite strange and
may well be the root of the problem is that all of the camera images
are labeled like this:
ImageName.jpg
Unknown format
xx.x kb
camera

Why are they "unknown format"? Are they not being recognized as jpg? I
did some testing and self.label has the value "None" at this point.
Commenting out the dc.DrawText lines allows it to run without
generating exceptions.

Vic

Roger Binns

2005-01-05 08:27:02 UTC

Post by Vic Heintz
Why are they "unknown format"? Are they not being recognized as jpg?

Technically I don't think they are legal JPEG images, but I made the
fileinfo code cope with that anyway. See this page for the
JPEG format:

http://www.funducode.com/freec/Fileformats/format3/format3b.htm

Your images skipped the APP0 marker and just went straight to
DQT (quantization table).

Roger

Roger Binns

2005-01-05 08:53:38 UTC

For the Mac folk, please let us know if all the wallpaper etc
stuff works now.

I am assuming it will and consequently plan on doing the build
tomorrow night (Weds).

Roger

Steven Palm

2005-01-05 17:40:48 UTC

For the Mac folk, please let us know if all the wallpaper etc stuff
works now.
I am assuming it will and consequently plan on doing the build
tomorrow night (Weds).

I haven't done extensive testing yet, but a quick run-through is fine
here visually. I cannot, however, save pictures out. The save dialog
appears, I pick a location and it goes away, but no file is ever
created. I don't think this is new, though, the last time I tried it I
don't think it worked for me either and that was quite a while ago,
although I thought others had it working. Add works, the "zooming in"
tooltip window is working, Refresh works, Paste works.... Basically
everything except saving.

Steve

Adit Panchal

2005-01-05 18:53:27 UTC

For the Mac folk, please let us know if all the wallpaper etc stuff
works now.
I am assuming it will and consequently plan on doing the build
tomorrow night (Weds).

I can confirm everything that Steve wrote - it does everything except
save. The new display code looks great to me!

Additionally, I believe the right click issue maybe related to a driver
issue or something like that. If nobody else on testing on Mac
experiences it, then that has to be the culprit. I have the Microsoft
Mouse drivers installed for my Intellimouse and am also using Sidetrack
to enable scrolling on my touchpad. Either of these could be the cause
of the problem.

I tested if evt.ButtonUp(wx.MOUSE_BTN_RIGHT) was true during the
OnRightClick and it always was, even if I was left clicking. For some
reason, all left and right clicks get sent as a right click, if I
already have the pop up menu open. This goes away if I click on a
different window or the tool bar. It also goes away if I select a menu
item. I also wanted to note that it did NOT happen at all with the old
bpmedia code. I tried to compare between the two, but nothing
significant seemed to be missing except the
self.SetRightClickMenus(self.menu, self.addfilemenu), which got removed
from guiwidgets.py when you started using the new aggregated display
code. I couldn't seem to find a implementation of this function in the
previous guiwidgets.py. Only the definition was present, but it worked
then.

It doesn't bother me, but it could get a bit annoying for the general
end user if this happened to them.

Adit

Roger Binns

2005-01-06 02:23:44 UTC

Post by Adit Panchal
item. I also wanted to note that it did NOT happen at all with the old
bpmedia code.

The old code used three widgets - a ListCtrl, a Grid and a HtmlWindow.
The ListCtrl handled dragging internally so presumably they may have been
doing some processing.

The new aggregatedisplay is just a subclass of wx.ScrolledWindow.

Post by Adit Panchal
I tried to compare between the two, but nothing significant

I double checked and couldn't see anything either.

Post by Adit Panchal
self.SetRightClickMenus(self.menu, self.addfilemenu), which got removed
from guiwidgets.py when you started using the new aggregated display
code.

Here is what it did (it was in bpmedia):

def SetRightClickMenus(self, itemmenu, bgmenu):
"""Sets the menus used for right click on an item and righ click on the background"""
self.itemmenu=itemmenu
self.bgmenu=bgmenu

You may understand why I removed it :-)

Post by Adit Panchal
It doesn't bother me, but it could get a bit annoying for the general
end user if this happened to them.

It looks specific to your machine.

Roger

Roger Binns

2005-01-06 02:36:06 UTC

the "zooming in" tooltip window is working,

Err, what on earth is the "zooming in" about? All the code does
is instantiate a wx.TipWindow if you rest your cursor over an
item for 1.750 sections. On Windows and Linux it just appears
in exactly the way as other tooltips do in other programs - no
zooming effects at all.

Roger

Adit Panchal

2005-01-06 03:01:53 UTC

the "zooming in" tooltip window is working,

For some reason on the Mac, with wxPython 2.5 and up, the default
behavior for all windows, and apparently tooltips is to zoom into view.
This is somewhat similar when you restore a window from the taskbar in
Windows, but a lot more visible, since it shows a dark black outline
for each zoom step. I think it is kind of annoying if you ask me.

I see your point about the right click code. It works fine on my
Windows box - I guess I just have to deal with it or uninstall some
drivers on the Mac. Thanks for the detailed info.

Adit

Steven Palm

2005-01-06 06:30:28 UTC

Post by Roger Binns
Err, what on earth is the "zooming in" about?

I think it's a fetish that Stephan Cosmor (apologies if I've butchered
his name) on the wxMac project has with that effect. It was a MacOS
thing in the early days, and I was really hoping it would go away...
There's the idea that when a window opens, you see a series of ever
growing rectangle outlines from the point of invocation to the
destination window size to make it feel like the window is growing up
from where you asked for it. Different strokes...

Roger Binns

2005-01-06 07:42:41 UTC

Post by Steven Palm
There's the idea that when a window opens, you see a series of ever
growing rectangle outlines from the point of invocation to the
destination window size to make it feel like the window is growing up
from where you asked for it. Different strokes...

That must be particularly annoying for the popups then ...

I presume he also made it impossible to turn off?

Roger

Steven Palm

2005-01-06 15:04:11 UTC

Post by Roger Binns
That must be particularly annoying for the popups then ...
I presume he also made it impossible to turn off?

Turn off? What does that mean? :-) (He must take lessons from
Steve Jobs... The user doesn't know what they want, it's up to the
developer to instruct them in such things. :-)

Vic Heintz

2005-01-04 19:07:40 UTC

Resize the window larger, at some point the vertical scroll bar goes
away and is replaced by a horizontal one.

Errr, that is impossible. I explicitly request only the vertical
scrollbar
and set the the horizontal scrollbar off. Line 340 of

I don't see this here at all, and it works fine... The initial load
of the Wallpaper images is excruciatingly slow for the few images that
I have, but once they load I can scroll up and down the whole view
without much problem. If I select refresh from the pop-up menu, it is
slow going again until they all reload, and then it speeds up again.

I really think the horizontal scrollbar that suddenly appears is a
remnant of a previously dismissed exception window. To see how truly
ugly these exception windows are under Mac OS Jaguar take a look at the
attached. I think it may be partly a problem that the window is bigger
than my 800X600 display and I can't grab the corner to resize it.

Since Steve is not seeing the same problems they could all be Jaguar
issues and not generic Mac issues. I'll try some of Roger's suggestions
to investigate this further. Since the majority of Mac users have
probably upgraded to Panther, if Steve says things are working OK, this
should probably not hold up a build. It won't be the first time a
Jaguar release was skipped. (I have been planning to jump right from
Jaguar to Tiger. Since I am using a clamshell G3 iBook, it should be
obvious I don't sit on the bleeding edge of technology.)

Vic

Adit Panchal

2005-01-05 04:27:16 UTC

Post by Vic Heintz
I really think the horizontal scrollbar that suddenly appears is a
remnant of a previously dismissed exception window. To see how truly
ugly these exception windows are under Mac OS Jaguar take a look at
the attached. I think it may be partly a problem that the window is
bigger than my 800X600 display and I can't grab the corner to resize
it.
Since Steve is not seeing the same problems they could all be Jaguar
issues and not generic Mac issues. I'll try some of Roger's
suggestions to investigate this further. Since the majority of Mac
users have probably upgraded to Panther, if Steve says things are
working OK, this should probably not hold up a build. It won't be the
first time a Jaguar release was skipped. (I have been planning to jump
right from Jaguar to Tiger. Since I am using a clamshell G3 iBook, it
should be obvious I don't sit on the bleeding edge of technology.)

I have a feeling these aren't Jaguar issues. Attached is a screenshot
that occurs on 10.3.7. I had to manually change my bitpim preferences
file to get out of starting in wallpaper mode. Otherwise I would get
stuck at that screen and it just won't go away - I can't resize, move,
or do anything with the exception window. The only thing I can do is
quit the process.

The ringers tab works fine, except for the fact if I right click on the
window, I can't get rid of the menu - left or right clicking keeps
bringing up the right click menu.

Adit

Roger Binns

2005-01-05 08:13:15 UTC

Post by Adit Panchal
The ringers tab works fine, except for the fact if I right click on the
window, I can't get rid of the menu - left or right clicking keeps
bringing up the right click menu.

Do you have your mouse buttons swapped? Only right clicking should
bring up a menu, and I only bind to right click events. (wxWidgets
is supposed to handle transposing mouse buttons for lefties but
maybe it is buggy for wxMac?)

You may want to see if the event can be interrogated in OnRightClick,
line 1064 of guiwidgets.py.

For example, event.ButtonUp(wx.MOUSE_BTN_RIGHT) should always be
true. If it isn't then unrequested events are coming in, but
can be ignored.

Roger

Roger Binns

2005-01-05 08:07:05 UTC

I've committed an updated exception dialog that behaves better when
there is a blizzard of exceptions (such as in a paint event as you
are experiencing). It is also smaller. You would think that it
would be resizable given a style of

wx.DEFAULT_DIALOG_STYLE|wx.RESIZE_BORDER|wx.THICK_FRAME|wx.MAXIMIZE_BOX

But apparently that isn't enough to be resizable ...

It now also includes an abort button that immediately terminates BitPim.

I was having a jolly old time crashing XP. Having exceptions in the
paint handler really threw XP for a loop, and I would end up with
an unusable machine (Windows redrew themselves all over screen, had
input in different location than their windows, everything was
drawn in the top left corner, the task manager wouldn't display
correctly etc etc. Pressing the reset button was my usual recourse.)

Thanks for sending me your wallpaper directory. The image information
is worked out in the fileinfo module. Unfortunately I can't wxImage
what was used to load an image, so that module does the work instead.
For some reason it doesn't identify your jpegs as jpeg, and instead
returns None as the format. Displaying that caused an exception in the
paint routine. Since the area still wasn't painted, the gui tries
to paint again, which causes another exception. Rinse and repeat.

Everything I have committed should fix all issues for you, with the
exception of the fileinfo which I am looking into now. (The JPEG
file format is one of the suckier ones out there.)

Roger

Vic Heintz

2005-01-05 12:34:34 UTC

Post by Vic Heintz
Why are they "unknown format"? Are they not being recognized as jpg?

Technically I don't think they are legal JPEG images, but I made the
fileinfo code cope with that anyway. See this page for the
http://www.funducode.com/freec/Fileformats/format3/format3b.htm
Your images skipped the APP0 marker and just went straight to
DQT (quantization table).

Is this something that can be easily repaired during the reads from the
camera? (An APP0 marker with a length of 0 perhaps?) As it is the
camera images have an additional 96 bytes at the head as they reside on
the camera. The Samsung A670 code strips this off during the get
wallpaper operation. I never investigated the format in any detail. I
was going by the popular wisdom which said that doing so left a jpg
which worked. Users at the time were getting the "image" files in
filesystem mode and using a hex editor to remove everything up to the
SOI marker. I merely automated this operation along with grabbing the
date/time stamp from this header. - Vic

Vic Heintz

2005-01-05 13:36:14 UTC

For the Mac folk, please let us know if all the wallpaper etc stuff
works now.
I am assuming it will and consequently plan on doing the build
tomorrow night (Weds).

Looking good on my Mac now. Nice work.

Vic

Vic Heintz

2005-01-05 18:34:53 UTC

For the Mac folk, please let us know if all the wallpaper etc stuff
works now.
I am assuming it will and consequently plan on doing the build
tomorrow night (Weds).

I can't say I've ever seen saving work for the Mac. I didn't even know
it was supposed to be an option until now. (I don't naturally
control-click on things to see what pops up like perhaps Windows users
do with right-clicks. ) In any case it behaves as Steve said.

Vic

Roger Binns

2005-01-06 02:33:09 UTC

Post by Vic Heintz
(I don't naturally
control-click on things to see what pops up like perhaps Windows users
do with right-clicks. )

You'll pretty much have no choice to do many operations. IMHO this is
the major UI area where Apple gets it wrong. There is very clear good
usability for being able to find out exactly operations are applicable
on an item at the item itself, rather than having to go elsewhere in
the UI.

Next closest to the user are toolbars or floating palettes. And lastly
the menu bar itself.

Once things do work better and we have a widget we are happy with
(this is now the *third* generation!) then I'll look into doing toolbars
and menu items. They are more of a pain since they have to be updated
on any item selection/deselection.

Roger

Steven Palm

2005-01-06 06:28:32 UTC

(I don't naturally control-click on things to see what pops up like
perhaps Windows users do with right-clicks. )

You'll pretty much have no choice to do many operations. IMHO this is
the major UI area where Apple gets it wrong.

Apple has gotten it quite right in MacOS X, though... Context
sensitive menus are very plentiful, it just can't be helped if some
people don't want to use them. <smirk>

Vic Heintz

2005-01-05 20:10:09 UTC

Post by Adit Panchal
I can confirm everything that Steve wrote - it does everything except
save. The new display code looks great to me!

I just happened to discover some images in my bitpim source directory.
It seems that on the Mac it is ignoring the selected directory path and
is saving the file there instead. Can you other Mac users confirm this
(Steve? Adit?)

Vic

Steven Palm

2005-01-05 20:22:56 UTC

Post by Adit Panchal
I can confirm everything that Steve wrote - it does everything except
save. The new display code looks great to me!

I just happened to discover some images in my bitpim source directory.
It seems that on the Mac it is ignoring the selected directory path
and is saving the file there instead. Can you other Mac users confirm
this (Steve? Adit?)

I looked everywhere... except there. :-) Yes, they are there. SO,
either the wx save dialog isn't returning the path, or it's somehow not
being properly prepended to the filename.

Steven Palm

2005-01-05 20:32:11 UTC

Post by Vic Heintz
I just happened to discover some images in my bitpim source directory.
It seems that on the Mac it is ignoring the selected directory path
and is saving the file there instead. Can you other Mac users confirm
this (Steve? Adit?)

I see... The call to wx.FileDialog is using wx.CHANGE_DIR, which
*SHOULD* be making the selected directory the current directory, and
thus that's where the file should be going when the copy routine is
done.

Roger, would you object to removing wx.CHANGE_DIR, and for the
shutil.copyfile() call using dlg.GetPath() instead of dlg.GetFileName()
? This works on the Mac, and I suspect would work everywhere. I just
didn't want to put this in as conditional code if you wouldn't mind
making it the default for all systems.

Roger Binns

2005-01-06 01:52:50 UTC

Post by Steven Palm
I see... The call to wx.FileDialog is using wx.CHANGE_DIR, which
*SHOULD* be making the selected directory the current directory,

The changedir is incidental to that. Its purpose is so that *next*
time you bring up the dialog, it starts in the last place you were
in.

Post by Steven Palm
thus that's where the file should be going when the copy routine is
done.

The error was that wxFileDialog.GetFilename() was used. I really
wanted the full name including path. I have just changed the code
to use GetPath() which is supposed to use the full name.

shutil.copyfile(items[0].filename, dlg.GetPath())

The code has been present for a long time, and was supposed to work
on all platforms. The wallpaper/ringtone widget just sucked before
so noone noticed :-)

Roger

Vic Heintz

2005-01-05 21:20:55 UTC

Post by Adit Panchal
I can confirm everything that Steve wrote - it does everything
except save. The new display code looks great to me!

I just happened to discover some images in my bitpim source
directory. It seems that on the Mac it is ignoring the selected
directory path and is saving the file there instead. Can you other
Mac users confirm this (Steve? Adit?)

I looked everywhere... except there. :-) Yes, they are there. SO,
either the wx save dialog isn't returning the path, or it's somehow
not being properly prepended to the filename.

Here is another twist. When I selected multiple files, it seems they
went where they were supposed to. _ Vic

Roger Binns

2005-01-06 01:58:53 UTC

Post by Vic Heintz
Here is another twist. When I selected multiple files, it seems they
went where they were supposed to. _ Vic

That is correct behaviour. If you have one file selected it wants
you to select a filename. If you have multiple then you have to
select a directory. See OnSave around line 1130 of guiwidgets.py.

Roger

Vic Heintz

2005-01-06 02:48:57 UTC

Post by Roger Binns
IMHO this is
the major UI area where Apple gets it wrong.

Perhaps. Why not a four-button mouse? Just think of all the control you
would have at your fingertips then. :-)

Roger Binns

2005-01-06 03:07:00 UTC

Post by Roger Binns
IMHO this is
the major UI area where Apple gets it wrong.

Perhaps. Why not a four-button mouse? Just think of all the control you
would have at your fingertips then. :-)

X Windows defines 5 buttons which you would have thought as a reasonable
maximum until they started putting multiple buttons on the side of a mouse.

The gains of going from one to two are very significant. Each additional
button has incrementally lower benefit. As an aside, when I buy mice
they have to meet the following criteria:

- Two main buttons
- Must have a scroll wheel
- The scroll wheel must 'click' as you rotate it
- It mustn't go side to side
- It mustn't be mushy (the latest trend)
- There must be a left side button that I can map to back in the browser
- It must be large (I have big hands)
- Preferably designed for a right handed person (the ambidextrous mice
tend to be ergonomically bad for either hand)

Roger

Vic Heintz

2005-01-06 03:19:30 UTC

the "zooming in" tooltip window is working,

Zooms open and zooms close. Not nearly as cool as the genie effect
though. :-)

John O'Shaughnessy

2005-01-06 03:21:49 UTC