headers
David Hough | 1 Feb 13:57

Re: Release? was Re: Stepping back as Zinf Debian

On Sat, 31 Jan 2004 11:42:56 +0000, Robert Hart <enxrah <at> nottingham.ac.uk> 
wrote:

> On Mon, 2004-01-26 at 19:47, Kristian G. Kvilekval wrote:
>
>> > 3.  File selector issues. - if I remember correctly pressing "open" 
>> from
>> > the main zinf window brings up a file selector, but it never seems
>> > capable of opening anything.
>>
>>  I can look at  this next week, unless someone beats me to it (hint).
>
> Ok. When I press "files" on the main zinf ui, I get three file selectors
> one after the other. Apart from that they seem to work ok (i.e. and
> files I select get added).
>
> As far as I can tell, the musicbrowser is receiving three CMD_AddFiles
> events. Is anybody else seeing this behaviour, and does it happen with
> the musicbrowserMM?
>
> I can't see why we would get triple events from one button, and not from
> others. except maybe that having the file-selector open freezes the ui,
> so maybe something gets lost.
>
> Rob

On my machine, normally I only get the one file selector which does indeed 
work properly. However, when I add some secondary ui's to my preferences, 
I get 1 file selector, and then another file selector for each secondary 
UI I have loaded, i.e. with two secondary ui's I'll get three file
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Hart | 1 Feb 16:49
Picon
Picon
Favicon

Re: Release? was Re: Stepping back as Zinf Debian

On Sun, 2004-02-01 at 12:57, David Hough wrote:

> On my machine, normally I only get the one file selector which does indeed 
> work properly. However, when I add some secondary ui's to my preferences, 
> I get 1 file selector, and then another file selector for each secondary 
> UI I have loaded, i.e. with two secondary ui's I'll get three file 
> selectors.
> 

Aha. I think you are on to something there. I was thinking to myself
that zinf never used to behave that way, so I was running through in my
mind all the bits of code that had changed. My initial assumption was
the file-selector code, because I took an axe to that when we switched
to GTK2, but I think I wrote the albumart&xosd ui's at about the same
time.

Me thinks I will need breathing apparatus before I dive far enough into
the zinf code to reach the event dispatch bits.

Rob

--

-- 
Robert Hart <enxrah <at> nottingham.ac.uk>

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Varshavchik | 1 Feb 17:01

Missing headers for make dist.

While packaging the current CVS in order to build Fedora RPMs I found some 
header files that were not packaged into the tarball by make dist.

The following patch fixes that:

https://sourceforge.net/tracker/index.php?func=detail&aid=888586&group_id=51494&atid=463481
Permalink | Reply | 2 comments |
headers
Robert Hart | 1 Feb 18:32
Picon
Picon
Favicon

Re: Release? was Re: Stepping back as Zinf Debian

On Sun, 2004-02-01 at 12:57, David Hough wrote:

> This suggests that there is only the one CMD_AddFiles event being sent, 
> but more then one UI is responding to it. I tried this with the albumart 
> and xosd ui's which I'm guessing have absolutely no code responding to 
> CMD_AddFiles. So, somehow when zinf loads a secondary UI does it also 
> loads another copy of the musicbrowser ui?

OMG. And the prize for dumbest bit of code ever goes to.....

Yes, basically for every ui on the list of things to load, zinf goes
through the entire list of available UIs, and if it finds a match, or it
finds the musicbrowser, or the download manager, load the ui.

Net result is you end up with a musicbrowser and a download manager for
every ui.

Fixed in CVS. btw. Is zinf-commits <at> lists.sourceforge.net broken? I get
the following error every time a commit something, and never get any
e-mail from it:

Generating notification message...
Traceback (most recent call last):
  File "/cvsroot/zinf/CVSROOT/syncmail", line 322, in ?
    main()
  File "/cvsroot/zinf/CVSROOT/syncmail", line 315, in main
    blast_mail(subject, people, specs[1:], contextlines, fromhost)
  File "/cvsroot/zinf/CVSROOT/syncmail", line 221, in blast_mail
    conn.connect(MAILHOST, MAILPORT)
  File "/usr/lib/python2.2/smtplib.py", line 276, in connect
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Hart | 1 Feb 19:13
Picon
Picon
Favicon

Re: Missing headers for make dist.

On Sun, 2004-02-01 at 16:01, Sam Varshavchik wrote:
> While packaging the current CVS in order to build Fedora RPMs I found some 
> header files that were not packaged into the tarball by make dist.
> 
> The following patch fixes that:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=888586&group_id=51494&atid=463481

Seems fairly innocuous so I applied it.

Do you find a project admin to create somewhere for you to upload your
RPMS? 

Rob

--

-- 
Robert Hart <enxrah <at> nottingham.ac.uk>

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Permalink | Reply | 1 comment |
headers
Sam Varshavchik | 1 Feb 20:38

Re: Missing headers for make dist.

Robert Hart writes:

> On Sun, 2004-02-01 at 16:01, Sam Varshavchik wrote:
>> While packaging the current CVS in order to build Fedora RPMs I found some 
>> header files that were not packaged into the tarball by make dist.
>> 
>> The following patch fixes that:
>> 
>> https://sourceforge.net/tracker/index.php?func=detail&aid=888586&group_id=51494&atid=463481
> 
> Seems fairly innocuous so I applied it.
> 
> Do you find a project admin to create somewhere for you to upload your
> RPMS? 

Nope.  Anyone?
Permalink | Reply | 0 comments |
headers
Roman Shiryaev | 2 Feb 16:16
Picon

updated russian translation

Hello,

There're an updated russian translation and little patch which 
marks some missing strings in the message attachment. Commit it, 
please.
Attachment (ru-zinf.tar.bz2): application/x-tbz, 16 KiB
Permalink | Reply | 0 comments |
headers
David Hough | 2 Feb 17:24

Re: "My Playlists" Tree Item in Browser

On Sat, 31 Jan 2004 11:36:29 +0000, Robert Hart <enxrah <at> nottingham.ac.uk> 
wrote:

> On Sat, 2004-01-31 at 01:58, David Hough wrote:
>
>> Anyway, has anyone got any objections to this, or any suggestions/ideas?
>
> I suppose the default could be a playlists directory within the .zinf
> folder. That should avoid any problems with names clashing.
>
> Sounds good to me.

O.K. I've almost finished the code for this now. You can set which 
directory to display in the preferences (defaults to ~/.zinf/playlists), 
and when saving a playlist the dialog has a combo with the current 
existing groups (sub directories) which you can type a new group into. It 
then creates a new directory and stores the playlist in there.

There is however one major problem with it still, it dosen't resolve the 
"~" part of the directory preference, so you end up with it looking in a 
sub dirctory of your current dir called "~" instead of looking in your 
home directory. So for the moment make sure your preferences have an 
absolute path for the dir if you want this to work.

I think this is something to do with the FilePathtoURL and ResolvePath 
functions in utilties.cpp but I'm not sure of the best way to fix this. 
Also, it looks like someone commented out some code that supposedly did 
this in ResolvePath, are there some portability issues or something with 
this? or was the code just never replaced?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kristian G. Kvilekval | 2 Feb 18:32
Picon
Gravatar

Re: "My Playlists" Tree Item in Browser

On Fri, 2004-01-30 at 17:58, David Hough wrote:
> Hi,
> 
> I'm thinking of changing how the "My Playlists" tree item is organised in 
> musicbrowsermm, and want to know if anyone has any views on what I'd like 
> to do.
> 
> I'm thinking of making the item actually represent a directory that can be 
> changed in the preferences. The two main reasons for this is to allow 
> grouping of playlists (using sub directories), and to make it easier to 
> share playlists between programs/operating systems as this would allow the 
> default location of playlists to be placed somewhere other then ~/.zinf
> So that you can still access playlists that aren't in the specified 
> directory, My Playlists would have an extra sub-item "Other Playlists" 
> that would read the list of playlists in the library.
> I've put an intial implementation of this in my tla archive, 
> david <at> thepriorities.com--2004/zinf--mdb--0.3--patch-2
> http://www-student.cs.york.ac.uk/~djh123/zinf/arch2004
> Its currently hard coded to represent ~/.zinf
> 
> If this idea were to used, then I think the default location for playlists 
> should be changed to ~/.zinf/playlists. The problem with using .zinf is 
> that it has a few sub-directories that are used for other things like the 
> database, etc. which would be listed in My Playlists by default, if we 
> stuck with .zinf as the default directory. Obvioulsy I could filter them 
> out but this is then restricting the possible names for playlists groups 
> (Yes, I know its highly unlikely that anyone will want a playlist group 
> called db or whatever, but its possible)
> 
> Anyway, has anyone got any objections to this, or any suggestions/ideas?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kristian G. Kvilekval | 2 Feb 18:33
Picon
Gravatar

Re: "My Playlists" Tree Item in Browser

On Sat, 2004-01-31 at 03:36, Robert Hart wrote:
> On Sat, 2004-01-31 at 01:58, David Hough wrote:

> Did we ever talking about ditching the "watch directory for music"
> feature. I remember discovering it was the cause of some unexplained
> crashes, but I don't think we ever fixed it.

I think it is turned off by default now.  I wanted to explore the
use of fam (file access monitor) that would accomplish the same
thing with polling for many system.

--

-- 
email:kris <at> cs.ucsb.edu office:(805)893-4276 http://www.cs.ucsb.edu/~kris

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Permalink | Reply | 0 comments |

Gmane