You can subscribe to this list here.
2000 |
Jan
(1) |
Feb
(4) |
Mar
(5) |
Apr
(2) |
May
(2) |
Jun
(4) |
Jul
|
Aug
(17) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(60) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(15) |
Feb
(73) |
Mar
(49) |
Apr
(38) |
May
(8) |
Jun
(4) |
Jul
(45) |
Aug
(53) |
Sep
(9) |
Oct
(35) |
Nov
(20) |
Dec
(1) |
2002 |
Jan
(21) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
From: Alexander F. <Ale...@gm...> - 2001-08-27 20:08:48
|
Hi! I will be away for one week from Saturday (2001-09-01). We will have to make the release at Friday or delay it for one week. If there are no strong reasons to delay it I would like to release 1.0.8 at Friday Comments? Alexander |
From: RAD K. 1 <kmr...@co...> - 2001-08-24 21:43:09
|
On Friday 24 August 2001 08:09, you wrote: > Perhaps we should make it clear somehow that it is the DEFAULT > setting for ISO options Right.. I think merely the word "Default" would clear everything up. > The settings in configure kreatecd are never per-session settings. I > think we need an additional button in the "Data CD only" mode. The > default configuration doesn't affect the data only CD track any more > - once it is constructed > > Alexander What I meant by "per-session" was something that is likely to change with each session (ie, the ISO settings). If the ISO settings in the configuration dialog are default settings then there is no way to configure an ISO in data only mode. Since of course they are, an additional button would definitely be needed. :) -- Kevin Radloff - RAD Kade 1 kmr...@co... http://shelled.nutz.org/~radkade1/ |
From: Alexander F. <Ale...@gm...> - 2001-08-24 14:18:17
|
On Friday, 24. August 2001 14:17, RAD Kade 1 wrote: > On Friday 24 August 2001 06:02, you wrote: > > Ok, but we have to do the rest too. The cancel button has to restore > > the old track again if the cancelled track was not a new track and > > the used changed it. To do this we will probably have to clone the > > complete CDTrack object - with all objects stored in it. I hope we > > manage this in time. > > > > Alexander > > Yeah, this is what I started doing then stopped when I realized there > were api issues with the CDTrack destructor deleting the objects it > references (which is bad if we copy the pointers :). I guess "bool > throwaway" or something in the constructor is a simple and only > slightly smelly fix. :) It is not the only problem that the destructor deletes the subobjects. The objects can be discared elsewhere too (when the user changes from audio track to data track (ISO 9660 mastering) - the AudioFileInfo gets discarded and an IsoImage object will be created ) Er even worse : the user only changes these objects - a cancel cannot undo these changes. I probably will implement copy constructors which will do a deep copy of the objects - not only pointers. Alexander |
From: RAD K. 1 <kmr...@co...> - 2001-08-24 12:17:56
|
On Friday 24 August 2001 06:02, you wrote: > Ok, but we have to do the rest too. The cancel button has to restore > the old track again if the cancelled track was not a new track and > the used changed it. To do this we will probably have to clone the > complete CDTrack object - with all objects stored in it. I hope we > manage this in time. > > Alexander Yeah, this is what I started doing then stopped when I realized there were api issues with the CDTrack destructor deleting the objects it references (which is bad if we copy the pointers :). I guess "bool throwaway" or something in the constructor is a simple and only slightly smelly fix. :) -- Kevin Radloff - RAD Kade 1 kmr...@co... http://shelled.nutz.org/~radkade1/ |
From: Alexander F. <Ale...@gm...> - 2001-08-24 12:13:23
|
On Friday, 24. August 2001 13:30, RAD Kade 1 wrote: > On Friday 24 August 2001 03:05, you wrote: > > OK, it annoys you with Adaptec EZCD creator, but does it annoy you > > with KreateCD? In the configuration dialog, one may set the > > standards, however, when the write CD button is pressed, one can > > change the burner settings there. > > > > Niels > > Sorry for being vague (Can't manage to get enough sleep for the life of > me lately :).. What I meant was that perhaps the ISO settings section > of the existing configuration dialog belongs in its own menu entry or > perhaps in a button or something. It's also ambiguous when using the > classic dialog; the user has no idea of knowing (without experimenting) > whether that changes existing ISO options or is the default or what (of > course, it is in fact the default behavior). Perhaps we should make it clear somehow that it is the DEFAULT setting for ISO options > If it's not functioning as > a dialog to set the default (in the case of the "Data CD only" > interface where it decides the final behavior), it seems slightly odd > that the options for the ISO are in a "Configure kreatecd" menu entry. > It seems to me that things belonging in a "configure kreatecd" dialog > are set once and forget about, while the ISO options are per-session. The settings in configure kreatecd are never per-session settings. I think we need an additional button in the "Data CD only" mode. The default configuration doesn't affect the data only CD track any more - once it is constructed Alexander |
From: Alexander F. <Ale...@gm...> - 2001-08-24 12:13:22
|
Hi! At the moment, the new TrackWindow - which has changed to QDialog - breaks AudioOptions. We'll have to this whether we have to change this back Alexander |
From: RAD K. 1 <kmr...@co...> - 2001-08-24 11:30:43
|
On Friday 24 August 2001 03:05, you wrote: > OK, it annoys you with Adaptec EZCD creator, but does it annoy you > with KreateCD? In the configuration dialog, one may set the > standards, however, when the write CD button is pressed, one can > change the burner settings there. > > Niels Sorry for being vague (Can't manage to get enough sleep for the life of me lately :).. What I meant was that perhaps the ISO settings section of the existing configuration dialog belongs in its own menu entry or perhaps in a button or something. It's also ambiguous when using the classic dialog; the user has no idea of knowing (without experimenting) whether that changes existing ISO options or is the default or what (of course, it is in fact the default behavior). If it's not functioning as a dialog to set the default (in the case of the "Data CD only" interface where it decides the final behavior), it seems slightly odd that the options for the ISO are in a "Configure kreatecd" menu entry. It seems to me that things belonging in a "configure kreatecd" dialog are set once and forget about, while the ISO options are per-session. -- Kevin Radloff - RAD Kade 1 kmr...@co... http://shelled.nutz.org/~radkade1/ |
From: Alexander F. <Ale...@gm...> - 2001-08-24 10:34:48
|
On Friday, 24. August 2001 09:05, Niels Reedijk wrote: > Op vrijdag 24 augustus 2001 04:14, schreef u: > > It seems to me that the add/edit track dialog is begging for cancel > > button; add a new track then think twice and your only option is to hit > > okay and then delete the track. So, here's the beginnings of a patch > > that adds said functionality. Though it handles the case of a new > > track, it doesn't do anything for editing an existing track. I was > > unsure of the direction to go in with this because of the existing > > object structure and the fact that the edit window changes the CDTrack > > object at the same time as dialog changes are made. > > > > I also changed TrackWindow to be a QDialog and made it modal. This > > seemed logical since really there's no reason for it to not be. It's > > not like you can open multiple edit dialogs (and this doesn't really > > make sense anyway). > > I applied the patch, everything looked reasonable. > Ok, but we have to do the rest too. The cancel button has to restore the old track again if the cancelled track was not a new track and the used changed it. To do this we will probably have to clone the complete CDTrack object - with all objects stored in it. I hope we manage this in time. > > Another issue I had in mind is configuration dialogs. One thing that > > really annoys me about adaptec ezcd creator is how it seems like the > > options that pertain to a specific burn and the options pertaining to > > the application/burner itself are mixed and spread over several > > dialogs. If you're just trying to do a quick burn, it's likely that > > you'll have to click all over the place. One thing that would be nice > > is if different types of configuration options are separated. > > Application/burner options can be in a dialog accessed through a menu, > > but it would be more convenient to have burn-specific options more > > easily accessible. > > OK, it annoys you with Adaptec EZCD creator, but does it annoy you with > KreateCD? In the configuration dialog, one may set the standards, however, > when the write CD button is pressed, one can change the burner settings > there. > I think it is OK like this. Are there any additional configuration options that should be in the write dialog? Alexander |
From: Niels R. <n.r...@pl...> - 2001-08-24 07:08:25
|
Op vrijdag 24 augustus 2001 04:14, schreef u: > It seems to me that the add/edit track dialog is begging for cancel > button; add a new track then think twice and your only option is to hit > okay and then delete the track. So, here's the beginnings of a patch > that adds said functionality. Though it handles the case of a new > track, it doesn't do anything for editing an existing track. I was > unsure of the direction to go in with this because of the existing > object structure and the fact that the edit window changes the CDTrack > object at the same time as dialog changes are made. > > I also changed TrackWindow to be a QDialog and made it modal. This > seemed logical since really there's no reason for it to not be. It's > not like you can open multiple edit dialogs (and this doesn't really > make sense anyway). I applied the patch, everything looked reasonable. > Another issue I had in mind is configuration dialogs. One thing that > really annoys me about adaptec ezcd creator is how it seems like the > options that pertain to a specific burn and the options pertaining to > the application/burner itself are mixed and spread over several > dialogs. If you're just trying to do a quick burn, it's likely that > you'll have to click all over the place. One thing that would be nice > is if different types of configuration options are separated. > Application/burner options can be in a dialog accessed through a menu, > but it would be more convenient to have burn-specific options more > easily accessible. OK, it annoys you with Adaptec EZCD creator, but does it annoy you with KreateCD? In the configuration dialog, one may set the standards, however, when the write CD button is pressed, one can change the burner settings there. Niels -- Ga eens wat vaker met de metro |
From: RAD K. 1 <kmr...@co...> - 2001-08-24 02:14:50
|
It seems to me that the add/edit track dialog is begging for cancel button; add a new track then think twice and your only option is to hit okay and then delete the track. So, here's the beginnings of a patch that adds said functionality. Though it handles the case of a new track, it doesn't do anything for editing an existing track. I was unsure of the direction to go in with this because of the existing object structure and the fact that the edit window changes the CDTrack object at the same time as dialog changes are made. I also changed TrackWindow to be a QDialog and made it modal. This seemed logical since really there's no reason for it to not be. It's not like you can open multiple edit dialogs (and this doesn't really make sense anyway). Another issue I had in mind is configuration dialogs. One thing that really annoys me about adaptec ezcd creator is how it seems like the options that pertain to a specific burn and the options pertaining to the application/burner itself are mixed and spread over several dialogs. If you're just trying to do a quick burn, it's likely that you'll have to click all over the place. One thing that would be nice is if different types of configuration options are separated. Application/burner options can be in a dialog accessed through a menu, but it would be more convenient to have burn-specific options more easily accessible. So.. Thoughts? Guidance? Opinions? :) -- Kevin Radloff - RAD Kade 1 kmr...@co... http://shelled.nutz.org/~radkade1/ |
From: Alexander F. <Ale...@gm...> - 2001-08-23 11:41:02
|
On Thursday, 23. August 2001 03:17, RAD Kade 1 wrote: > Here's a simple fix for the new project selection dialog displaying the > wrong picture if the default is set to anything but the first option. Thanks for the patch. It is applied to CVS. Alexander |
From: RAD K. 1 <kmr...@co...> - 2001-08-23 01:17:27
|
Here's a simple fix for the new project selection dialog displaying the wrong picture if the default is set to anything but the first option. -- Kevin Radloff - RAD Kade 1 kmr...@co... http://shelled.nutz.org/~radkade1/ |
From: Niels R. <n.r...@pl...> - 2001-08-22 19:34:08
|
-- Ga eens wat vaker met de metro |
From: Joseph W. <jo...@bi...> - 2001-08-22 12:37:13
|
Hi > The fix seems ok to me and it seems to work. If nobody objects I will > commit this to CVS The fix was that trivial, I nearly rewrote each line here on my local system, but I didn't reallise where the problem had been. (It seam I should sleep more, 2h/day isn't enough) Yes, commit it Kind regards Joseph Wenninger |
From: Alexander F. <Ale...@gm...> - 2001-08-22 12:22:25
|
Hi! As you might have seen, Kevin Radloff posted a fix for the DND which is initiated when clicking on the + sign and the contents of the widget are scrolled. This is the REVERSED patch: --- FileTree.cpp Tue Aug 21 21:42:28 2001 +++ /usr/local/src/kreatecd-1.0.7/kreatecd/FileTree.cpp Mon Apr 30 15:52:38 2001 @@ -517,6 +517,7 @@ void FileTree::contentsMousePressEvent ( QMouseEvent * e ) { + QListView::contentsMousePressEvent (e); if (!sourceonly) return; QPoint p(contentsToViewport(e->pos())); FileTreeItem *i = (FileTreeItem*)itemAt(p); @@ -526,7 +527,6 @@ m_dragPos=e->pos(); m_bDrag=true; } - QListView::contentsMousePressEvent (e); } void FileTree::contentsMouseReleaseEvent ( QMouseEvent * ) { The fix seems ok to me and it seems to work. If nobody objects I will commit this to CVS Alexander |
From: Joseph W. <jo...@bi...> - 2001-08-19 19:44:35
|
Hi > > We could meet in IRC - either in openprojects.net or in another IRC net. > IRC is a simple outgoing TCP connection to a known target - without the > need to let some inbound ports open. > Would be nice to meet both of you on IRC, I'm quite often on the openprojects net in the #kde channel Kind regards Joseph Wenninger |
From: Alexander F. <Ale...@gm...> - 2001-08-19 19:08:44
|
On Sunday, 19. August 2001 20:09, Niels Reedijk wrote: > Op zondag 19 augustus 2001 20:08, schreef u: > > Then we can begin to do binary packaging. > > Allright. > Just uploading the packages to sourceforge net. They should be available in the next minutes. > > What is that? A messanger programm? Probably it won't get through my > > paranoid firewall :) > > Ahhh, too bad ;-) > > N. We could meet in IRC - either in openprojects.net or in another IRC net. IRC is a simple outgoing TCP connection to a known target - without the need to let some inbound ports open. Alexander |
From: Niels R. <n.r...@pl...> - 2001-08-19 18:12:11
|
Op zondag 19 augustus 2001 20:08, schreef u: > Then we can begin to do binary packaging. Allright. > What is that? A messanger programm? Probably it won't get through my > paranoid firewall :) Ahhh, too bad ;-) N. -- Ga eens wat vaker met de metro |
From: Alexander F. <Ale...@gm...> - 2001-08-19 18:08:45
|
On Sunday, 19. August 2001 19:46, Niels Reedijk wrote: > Op zondag 19 augustus 2001 17:09, schreef u: > > Do we create binary packages as usual or is this a source only release? > > Let's do binary. > Just tagged CVS and I am currently building the source packages. I will upload them ASAP. Then we can begin to do binary packaging. > Niels > > P.S. Do you have KMsn? What is that? A messanger programm? Probably it won't get through my paranoid firewall :) Alexander |
From: Niels R. <n.r...@pl...> - 2001-08-19 17:49:10
|
Op zondag 19 augustus 2001 17:09, schreef u: > Do we create binary packages as usual or is this a source only release? Let's do binary. Niels P.S. Do you have KMsn? -- Ga eens wat vaker met de metro |
From: Alexander F. <Ale...@gm...> - 2001-08-19 16:31:04
|
On Sunday, 19. August 2001 13:59, Niels Reedijk wrote: > I can't really reproduce this behaviour... > > What I want to do at install time is: > a) remove the common subdir > b) install our common subdir > > the common subdirs lack some things we need. > Is the install-data-local executed by make install? It might be the case that it is executed before the rest of make install is executed. I don't know if there is any order installation takes place. We could force that install-data-local takes place later if we add an dependency on it - to depend on the other installation steps. But we would have to make sure that these dependencies exists - otherwise make install will fail Alexander |
From: Alexander F. <Ale...@gm...> - 2001-08-19 16:31:03
|
On Friday, 17. August 2001 23:03, Niels Reedijk wrote: > Hi, > > Read this: > http://linuxtoday.com/news_story.php3?ltsn=2001-08-17-002-20-NW-CY > > This article really got me thinking. The > "This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 of the License, or > (at your option) any later version." > > line is quite dangerous. what if the FSF (or whoever owns the license) > decides to release a new version with a commercial clausule (so the fSF may > sell commercial licenses...) we can't do anything about it. > Do you mean that they could write a new version of the license where FSF is allowd to sell kreatecd for money and forbid to copy kreatecd? I think this should be not possible as this "or any version later" is an optional choice of the user. The only thing that could happen - if version 3 has such a clause - that FSF does own development based upon kreatecd and license this under version 3 - because they have the choice to choose from version 2 and above - they can do that. > What I want to say is, that I'm really shocked by this. I'm not saying that > we actually should change license :-) > > (Though I'm thinking about removing the "or (at your option) any later > version" clause). > > what do you think? We could do that. But AFAIK all developers have to agree. As far as I understand we cannot change the license any more if one person is unable to act (e.g. he is dead, moved to a country where he cannot be reached or similar things). If we change now to "version 2 only" we can only upgrade to version 3 (which might be better or worse) if all developers agree again. I'm not a lawyer and don't know very much about these legal things. Where could we get more information about the pros and cons to remove the "license upgrade clause" Alexander |
From: Alexander F. <Ale...@gm...> - 2001-08-19 15:11:56
|
On Sunday, 19. August 2001 14:09, Niels Reedijk wrote: > Alexander, what commands do you do to create the packages? I wnt to test > the suse spec, see if it is still up to date. Usually I do an export of the CVS tree - to get rid of the CVS directories and call make -f Makefile.cvs to create the configure stuff. Then I duplicate this tree , make a test compilation with one and if this succeeds, I create a tarball of the untouched tree. We might change this to provide HTML doc files. A "make distclean" should result in a clean kreatecd source tree ready for packaging - if distclean is not broken. Do we create binary packages as usual or is this a source only release? Mandrake cooker probably gets updated soon - kreatecd is currently in contrib there. Alexander |
From: Niels R. <n.r...@pl...> - 2001-08-19 12:11:53
|
Alexander, what commands do you do to create the packages? I wnt to test the suse spec, see if it is still up to date. Niels -- Ga eens wat vaker met de metro |
From: Niels R. <n.r...@pl...> - 2001-08-19 12:09:19
|
Op zondag 19 augustus 2001 14:21, schreef u: > Why do we need to change the common subdir ? Should images, ..... not stay > in the applications documentation directory ? The common dir is actually a symlink leading to the common subdir of KDE 2.1.1 or less. Because our documents are compiled against KDE 2.2, which defines a few other images and a new stylesheet only available in the KDE 2.2 subdir, we need this subdir. Niels -- Ga eens wat vaker met de metro |