Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sun, Mar 20, 2011 at 5:41 PM, Christoph Bartoschek wrote: > Am Sonntag 20 März 2011 schrieb todd rme: >> Just out of curiosity, what widget style is being used for the >> screenshots? > > This should be oxygen from KDE 4.4 Is it a problem that the dialog doesn't look like a native dialog? It doesn't really seem to match with anything else in KDE. -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Sonntag 20 März 2011 schrieb todd rme: > On Sun, Mar 20, 2011 at 4:02 PM, John Layt wrote: > > On Sunday 20 Mar 2011 17:48:09 Christoph Bartoschek wrote: > >> Hi, > >> > >> do you refer to the dialog I see for one of our printers? Which > >> options do you want to see? The "General" tab? > >> > >> By the way, is there any reason to prevent resizing of the dialog? > >> > >> I've disabled this and made 3 screenshots showing the general dialog. > >> > >> http://www.pontohonk.de/screenshots/cpd-1.png > >> http://www.pontohonk.de/screenshots/cpd-2.png > >> http://www.pontohonk.de/screenshots/cpd-3.png > >> > >> Christoph > > > > Wow, thats some set of printer options :-) Definately too long. > > > > As I've said earlier, the dialog still needs polishing, and the options > > filtering looks to be one of those things needing work. Cases like this > > will be a good test of the usability design. I think the big problem > > is people will need to unlearn that those are tabs with fixed groups of > > settings, but rather filters that can be mixed and matched to produce > > dynamic results. > > > > John. > > Just out of curiosity, what widget style is being used for the > screenshots? This should be oxygen from KDE 4.4
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Sonntag 20 März 2011 schrieb John Layt: > Hi, > > Some very good points, some definately belong in the dialog, others belong > in CUPS itself, but I'll take them all with me as everyone will be at the > summit. For me as user it does not matter where it is implemented. However I think this all should be controlled by the print dialog. I do not want to have some options in the cups configuration and some options in the print dialog. There will definitively be conflicts between the options and users will be confused. I would like to compare it with the mess one has with volume control. There are about 5 levels on which I can control the volume on my system. This are 4 too much. For printers a similar issue is the portrait/landscape mode. This can sometimes be specified in the application, the print dialog and the cups system. It never works as expected. > > - My biggest wish for a printing dialog is that the preview exactly > > matches the output. All current print dialogs that I know on linux have > > the problem that the output is not really predictible if one goes away > > from the default: printing A4 portrait to an A4 portrait printer. > > This is actually a very hard thing to do, basically it would involve > asking the print system (in our case CUPS) to process the print job right > up to the point of sending it to the printer, then to give us back the > processed job to use for the preview which would be close, but there's > always a conversion process from the job format (was ps, soon to be pdf) > into the printer format (e.g. PCL) as there's very few printers that > speak ps or pdf natively. So there's always a chance something will > still not look right. All this back- and-forth of course adds overhead > and slows the process down. I know there's a wish for this in the CUPS > bugzilla. > > At the moment the CPD uses poppler to render the pdf print file as the > preview, and then does manipulations on that pdf to simulate what CUPS > would do. I assume the filters it applies to the preview pdf are the > same ones used in CUPS so it should be fairly close. If one only uses poppler to simulate the processing of CUPS then the dialog is a failure. There will definitively be differences which lead to confusion. In my opinion CUPS should not do any processing but just convert a PDF to the printer`s language and send it to the printer. The print dialog can then apply all necessary filters to get the desired output. This is the only way to ensure that the output is as expected. > > - The choice of the output paper size and tray should be more prominent. > > I have one printer where I can find the paper size only in the General > > tab at the last position of 50 options. > > The design of the CPD is that all the options will appear in the one area, > no more tabs or separate Properties dialog. To control what options > appear at any one time there will be a number of filters you can apply > and even a search box. You'll also be able to save groups of presets. > The default should be the most commonly used options. It's the polish on > this stuff that the dialog is currently lacking and is planned for this > years GSoC. > > It will be interesting to see if this works as well in practice as the > usability engineers designed it to. > > > - There should be visual feedback how the document applies to the paper. > > What happens if I print an A4 document and select an A5 paper? How can I > > specify that the document has to be shrunk to fit? > > > > - For duplex printing I would like to see a left and right page or top > > and down page side by side in the preview. > > > > - The preview should optionally show the media borders, the printable > > area borders and the document borders on the media. > > These should all be part of the dialog preview, I'll see if it's in the > design or not, it could be one of the unimplemented things. > > > - Is it possible let the dialog shrink the document by a given > > percentage and to align the document on the paper to have more empty > > space on the left for a hole-puncher > > This is usually best achieved using a word processor and setting different > margins for odd/even pages, but not every app can do that, so it sounds > like a good idea for CUPS to implement. CUPS can certainly apply the > shrink, and it can apply the paper margins, but I don't think it can > currently vary the margins based on page being odd/even. I have the problem when I am printing scientific papers. Printing documents that are designed for letter on A4 printers results in very small margins. > > - Is it possible to print an A5 document on A4 paper centered with > > optional with crop marks at the border? > > I've think I've seen Adobe Acrobat do that on Windows? It would be a nice > CUPS option, but something the dialog could generate too with a filter. > > > - Will the applications be able to change the document and send a new > > preview as soon
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sun, Mar 20, 2011 at 4:02 PM, John Layt wrote: > On Sunday 20 Mar 2011 17:48:09 Christoph Bartoschek wrote: >> Hi, >> >> do you refer to the dialog I see for one of our printers? Which options do >> you want to see? The "General" tab? >> >> By the way, is there any reason to prevent resizing of the dialog? >> >> I've disabled this and made 3 screenshots showing the general dialog. >> >> http://www.pontohonk.de/screenshots/cpd-1.png >> http://www.pontohonk.de/screenshots/cpd-2.png >> http://www.pontohonk.de/screenshots/cpd-3.png >> >> Christoph > > Wow, thats some set of printer options :-) Definately too long. > > As I've said earlier, the dialog still needs polishing, and the options > filtering looks to be one of those things needing work. Cases like this will > be a good test of the usability design. I think the big problem is people > will need to unlearn that those are tabs with fixed groups of settings, but > rather filters that can be mixed and matched to produce dynamic results. > > John. Just out of curiosity, what widget style is being used for the screenshots? -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sunday 20 Mar 2011 17:48:09 Christoph Bartoschek wrote: > Hi, > > do you refer to the dialog I see for one of our printers? Which options do > you want to see? The "General" tab? > > By the way, is there any reason to prevent resizing of the dialog? > > I've disabled this and made 3 screenshots showing the general dialog. > > http://www.pontohonk.de/screenshots/cpd-1.png > http://www.pontohonk.de/screenshots/cpd-2.png > http://www.pontohonk.de/screenshots/cpd-3.png > > Christoph Wow, thats some set of printer options :-) Definately too long. As I've said earlier, the dialog still needs polishing, and the options filtering looks to be one of those things needing work. Cases like this will be a good test of the usability design. I think the big problem is people will need to unlearn that those are tabs with fixed groups of settings, but rather filters that can be mixed and matched to produce dynamic results. John.
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sunday 20 Mar 2011 16:50:22 todd rme wrote: > In general it would be nice to see screenshots of the available > options and how they are laid out. > > -Todd I'd post some but for two problems. 1) It segfaults on my machine right now, some Qt issue 2) The ui interaction is really not close to being finished. At the moment it's mostly the backend and basic dialog that's done, finishing the dialog is this years GSoC project which is why it's the perfect time for us to jump in and influence things. The interaction has actually been designed by professional usability designers and tested in usability labs, so it should turn out good if we can get the same results in code. Cheers! John.
Re: OpenPrinting Summit - Print Dialog and Colour Management
Hi, Some very good points, some definately belong in the dialog, others belong in CUPS itself, but I'll take them all with me as everyone will be at the summit. > - My biggest wish for a printing dialog is that the preview exactly matches > the output. All current print dialogs that I know on linux have the problem > that the output is not really predictible if one goes away from the > default: printing A4 portrait to an A4 portrait printer. This is actually a very hard thing to do, basically it would involve asking the print system (in our case CUPS) to process the print job right up to the point of sending it to the printer, then to give us back the processed job to use for the preview which would be close, but there's always a conversion process from the job format (was ps, soon to be pdf) into the printer format (e.g. PCL) as there's very few printers that speak ps or pdf natively. So there's always a chance something will still not look right. All this back- and-forth of course adds overhead and slows the process down. I know there's a wish for this in the CUPS bugzilla. At the moment the CPD uses poppler to render the pdf print file as the preview, and then does manipulations on that pdf to simulate what CUPS would do. I assume the filters it applies to the preview pdf are the same ones used in CUPS so it should be fairly close. > - The choice of the output paper size and tray should be more prominent. I > have one printer where I can find the paper size only in the General tab at > the last position of 50 options. The design of the CPD is that all the options will appear in the one area, no more tabs or separate Properties dialog. To control what options appear at any one time there will be a number of filters you can apply and even a search box. You'll also be able to save groups of presets. The default should be the most commonly used options. It's the polish on this stuff that the dialog is currently lacking and is planned for this years GSoC. It will be interesting to see if this works as well in practice as the usability engineers designed it to. > - There should be visual feedback how the document applies to the paper. > What happens if I print an A4 document and select an A5 paper? How can I > specify that the document has to be shrunk to fit? > - For duplex printing I would like to see a left and right page or top and > down page side by side in the preview. > - The preview should optionally show the media borders, the printable area > borders and the document borders on the media. These should all be part of the dialog preview, I'll see if it's in the design or not, it could be one of the unimplemented things. > - Is it possible let the dialog shrink the document by a given percentage > and to align the document on the paper to have more empty space on the > left for a hole-puncher This is usually best achieved using a word processor and setting different margins for odd/even pages, but not every app can do that, so it sounds like a good idea for CUPS to implement. CUPS can certainly apply the shrink, and it can apply the paper margins, but I don't think it can currently vary the margins based on page being odd/even. > - Is it possible to print an A5 document on A4 paper centered with optional > with crop marks at the border? I've think I've seen Adobe Acrobat do that on Windows? It would be a nice CUPS option, but something the dialog could generate too with a filter. > - Will the applications be able to change the document and send a new > preview as soon as the options change? Yes, that's part of the protocol, as soon as any option that affects the document layout changes (as opposed to affecting the printed page layout), then the dialog tells the app and requests a new preview. It will be interesting to see what performance lag there is as a result. > - If one prints more than one document page on a paper sheet it should be > possible to specify the horizontal and vertical gaps. That's definately a new CUPS setting, as it's CUPS that processes the n-up stuff. > - One advanced option I would like to see: I do not know of any duplex > printer that is able to print the front and back page such that for example > crop marks exactly match. Often there is an offset one has to apply. It > would be nice if one could do this independently for the front and back > page in the dialog. Oooo, tricky. Again probably a CUPS thing? I'll ask anyway. It's good to know we have some advanced printer users about, I have very limited needs and resources myself so there's stuff I just won'think of. Cheers! John.
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Sonntag 20 März 2011 schrieb Christoph Bartoschek: > I've disabled this and made 3 screenshots showing the general dialog. > > http://www.pontohonk.de/screenshots/cpd-1.png > http://www.pontohonk.de/screenshots/cpd-2.png > http://www.pontohonk.de/screenshots/cpd-3.png The screenshots show another problem of the dialog. The pdf page size is 128mmx96mm. The default page size of the printer is A4. The preview gives no idea how the document will look on the sheet paper. Christoph
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Sonntag 20 März 2011 schrieb todd rme: > On Sun, Mar 20, 2011 at 10:10 AM, Christoph Bartoschek > > wrote: > > Am Mittwoch 16 März 2011 schrieb John Layt: > >> [1] > >> > >> https://www.linuxfoundation.org/collaborate/workgroups/openprinting/ope > >> npr > >> > >> inting- summit-san-francisco-2011 > >> > >> [2] > >> > >> http://www.linuxfoundation.org/collaborate/workgroups/openprinting/comm > >> onp > >> > >> rintingdialog > > > > Hi, > > > > I'm very happy to read that there is work to improve the current > > printing situation. KDE 3 had a wonderful printing system. It was far > > from perfect but usable. Unfortunately KDE 4 replaced it with a print > > dialog that is barely usable. > > > > I've looked at the Requirements page and started the dialog application. > > I have some comments and questions: > > > > - My biggest wish for a printing dialog is that the preview exactly > > matches the output. All current print dialogs that I know on linux have > > the problem that the output is not really predictible if one goes away > > from the default: printing A4 portrait to an A4 portrait printer. > > > > Often one has to try several options to get the desired result or one > > finally fails. Options that often cause problems are landscape/portrait > > the size of the media, or multiple pages printing. > > > > - The choice of the output paper size and tray should be more prominent. > > I have one printer where I can find the paper size only in the General > > tab at the last position of 50 options. > > > > - There should be visual feedback how the document applies to the paper. > > What happens if I print an A4 document and select an A5 paper? How can I > > specify that the document has to be shrunk to fit? > > > > - Is it possible let the dialog shrink the document by a given > > percentage and to align the document on the paper to have more empty > > space on the left for a hole-puncher > > > > - Is it possible to print an A5 document on A4 paper centered with > > optional with crop marks at the border? > > > > - Will the applications be able to change the document and send a new > > preview as soon as the options change? > > > > - For duplex printing I would like to see a left and right page or top > > and down page side by side in the preview. > > > > - If one prints more than one document page on a paper sheet it should > > be possible to specify the horizontal and vertical gaps. > > > > - The preview should optionally show the media borders, the printable > > area borders and the document borders on the media. > > > > - One advanced option I would like to see: I do not know of any duplex > > printer that is able to print the front and back page such that for > > example crop marks exactly match. Often there is an offset one has to > > apply. It would be nice if one could do this independently for the > > front and back page in the dialog. > > > > Christoph Bartoschek > > In general it would be nice to see screenshots of the available > options and how they are laid out. Hi, do you refer to the dialog I see for one of our printers? Which options do you want to see? The "General" tab? By the way, is there any reason to prevent resizing of the dialog? I've disabled this and made 3 screenshots showing the general dialog. http://www.pontohonk.de/screenshots/cpd-1.png http://www.pontohonk.de/screenshots/cpd-2.png http://www.pontohonk.de/screenshots/cpd-3.png Christoph
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sun, Mar 20, 2011 at 10:10 AM, Christoph Bartoschek wrote: > Am Mittwoch 16 März 2011 schrieb John Layt: > >> [1] > >> https://www.linuxfoundation.org/collaborate/workgroups/openprinting/openpr > >> inting- summit-san-francisco-2011 > >> [2] > >> http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonp > >> rintingdialog > > Hi, > > I'm very happy to read that there is work to improve the current printing > situation. KDE 3 had a wonderful printing system. It was far from perfect > but usable. Unfortunately KDE 4 replaced it with a print dialog that is > barely usable. > > I've looked at the Requirements page and started the dialog application. I > have some comments and questions: > > - My biggest wish for a printing dialog is that the preview exactly matches > the output. All current print dialogs that I know on linux have the problem > that the output is not really predictible if one goes away from the default: > printing A4 portrait to an A4 portrait printer. > > Often one has to try several options to get the desired result or one > finally fails. Options that often cause problems are landscape/portrait the > size of the media, or multiple pages printing. > > - The choice of the output paper size and tray should be more prominent. I > have one printer where I can find the paper size only in the General tab at > the last position of 50 options. > > - There should be visual feedback how the document applies to the paper. > What happens if I print an A4 document and select an A5 paper? How can I > specify that the document has to be shrunk to fit? > > - Is it possible let the dialog shrink the document by a given percentage > and to align the document on the paper to have more empty space on the left > for a hole-puncher > > - Is it possible to print an A5 document on A4 paper centered with optional > with crop marks at the border? > > - Will the applications be able to change the document and send a new > preview as soon as the options change? > > - For duplex printing I would like to see a left and right page or top and > down page side by side in the preview. > > - If one prints more than one document page on a paper sheet it should be > possible to specify the horizontal and vertical gaps. > > - The preview should optionally show the media borders, the printable area > borders and the document borders on the media. > > - One advanced option I would like to see: I do not know of any duplex > printer that is able to print the front and back page such that for example > crop marks exactly match. Often there is an offset one has to apply. It > would be nice if one could do this independently for the front and back page > in the dialog. > > Christoph Bartoschek In general it would be nice to see screenshots of the available options and how they are laid out. -Todd
Re: 4.6 branches created in git again
On Sunday, 20 de March de 2011 15:09:26 Andreas Hartmetz wrote: > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: > > Can you please be careful and do not create incorrectly 4.6 branches in > > places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) > > > > Ian can you kill them? > > > > Albert > > Maybe we can go through with renaming the branches to n.m (without KDE/) > prefix? > Some repositories have the prefix, some don't, I think it doesn't make sense > to have the prefix, and it was decided (by tossing a coin...) that the > prefix should be removed. Suggestion: create a symbolic-ref from one to the other. Then the two branches are always one: push to one will update the other. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: 4.6 branches created in git again
On Sunday 20 March 2011, Parker Coates wrote: > On Sun, Mar 20, 2011 at 10:57, Ian Monroe wrote: > > On Sun, Mar 20, 2011 at 09:45, John Tapsell wrote: > >> Why do we let people create branches on the main git server > >> anyway? > > > > Well for feature branches its fine and kind of the point of git. > > There's no reason to let non-admins create version branches though. > > Extragear? I'm pretty sure that everybody understands that this only applies to SC repositories. So, don't worry. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: 4.6 branches created in git again
On 03/20/2011 04:17 PM, John Tapsell wrote: By having it in your own git repository. This is how Qt does it. Anyone can clone the Qt repository on the server and create branches in their own clone. For example, here is mine: http://qt.gitorious.org/~johnflux- and other people can (and do) work on it. In case someone accidentally misreads that as a suggestion to use Gitorious: Note that git.kde.org supports server-side per- sonal clones as well. (Plus personal repositories, which Gito- rious doesn't.) John -- Best regards, Eike Hein
Re: 4.6 branches created in git again
On Sunday 20 Mar 2011 15:02:49 Alexander Neundorf wrote: > On Sunday 20 March 2011, Parker Coates wrote: > > On Sun, Mar 20, 2011 at 10:09, Andreas Hartmetz wrote: > > > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: > > >> Can you please be careful and do not create incorrectly 4.6 branches > > >> in places where the branch is called KDE/4.6 (e.g kdelibs and > > >> kde-runtime) > > >> > > >> Ian can you kill them? > > > > > > Maybe we can go through with renaming the branches to n.m (without > > > KDE/) prefix? > > > > I think keeping the prefix is the superior option. For kdelibs, > > kderuntime, kdeworkspace, etc. it really doesn't make any difference, > > but for something like, say, Konsole the difference is important. If > > one sees a branch named "4.6" in the Konsole repository, one is likely > > to assume that it represents Konsole 4.6, when in fact it represents > > Konsole 2.6 which is part of KDE SC 4.6. Keeping the "KDE/" prefix > > helps clarify this. > > I agree. > In doubt, be explicit. > > Alex Exactly. Another argument now is sheer volume, I think more people will have checkouts of kdelibs and kdebase with the prefix than will have checkouts of the repos without the prefix, so it will now be less disruptive to keep KDE/. A month ago it would have been different. John.
Re: 4.6 branches created in git again
On 20 March 2011 15:01, Albert Astals Cid wrote: > A Diumenge, 20 de març de 2011, John Tapsell va escriure: >> Why do we let people create branches on the main git server anyway? > > How are you supposed to work on a feature-branch otherwise? By having it in your own git repository. This is how Qt does it. Anyone can clone the Qt repository on the server and create branches in their own clone. For example, here is mine: http://qt.gitorious.org/~johnflux- and other people can (and do) work on it. John
Re: 4.6 branches created in git again
On Sunday 20 March 2011 15:59:55 Parker Coates wrote: > On Sun, Mar 20, 2011 at 10:09, Andreas Hartmetz wrote: > > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: > >> Can you please be careful and do not create incorrectly 4.6 branches in > >> places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) > >> > >> Ian can you kill them? > > > > Maybe we can go through with renaming the branches to n.m (without KDE/) > > prefix? > > I think keeping the prefix is the superior option. For kdelibs, > kderuntime, kdeworkspace, etc. it really doesn't make any difference, > but for something like, say, Konsole the difference is important. If > one sees a branch named "4.6" in the Konsole repository, one is likely > to assume that it represents Konsole 4.6, when in fact it represents > Konsole 2.6 which is part of KDE SC 4.6. Keeping the "KDE/" prefix > helps clarify this. > Right, I didn't think of that... AFAIK we have some modules where the branch is called 4.6. They aren't that many, and can we fix them then?
Re: 4.6 branches created in git again
On Sunday 20 March 2011, Parker Coates wrote: > On Sun, Mar 20, 2011 at 10:09, Andreas Hartmetz wrote: > > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: > >> Can you please be careful and do not create incorrectly 4.6 branches in > >> places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) > >> > >> Ian can you kill them? > > > > Maybe we can go through with renaming the branches to n.m (without KDE/) > > prefix? > > I think keeping the prefix is the superior option. For kdelibs, > kderuntime, kdeworkspace, etc. it really doesn't make any difference, > but for something like, say, Konsole the difference is important. If > one sees a branch named "4.6" in the Konsole repository, one is likely > to assume that it represents Konsole 4.6, when in fact it represents > Konsole 2.6 which is part of KDE SC 4.6. Keeping the "KDE/" prefix > helps clarify this. I agree. In doubt, be explicit. Alex
Re: 4.6 branches created in git again
On Sunday 20 Mar 2011 14:28:11 Andreas Hartmetz wrote: > On Sunday 20 March 2011 15:17:11 Ian Monroe wrote: > > On Sun, Mar 20, 2011 at 09:09, Andreas Hartmetz wrote: > > > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: > > >> Can you please be careful and do not create incorrectly 4.6 branches > > >> in places where the branch is called KDE/4.6 (e.g kdelibs and > > >> kde-runtime) > > >> > > >> Ian can you kill them? > > >> > > >> Albert > > > > > > Maybe we can go through with renaming the branches to n.m (without > > > KDE/) prefix? > > > Some repositories have the prefix, some don't, I think it doesn't make > > > sense to have the prefix, and it was decided (by tossing a coin...) > > > that the prefix should be removed. > > > > This would just cause more chaos until we block the creation of > > whatever the non-favored naming scheme is. > > I'd suggest doing exactly that no matter if the branch names are changed or > not. It's a necessary pre-requisite for the rename, or chaos will reign. I'll declare here I prefer a prefix simply for organisation and grep-ability and to to make it official looking, perhaps a compromise of origin/Release/4.6? Anyway, if we do declare straight numbers the winner, the following rules should apply: 1) Any branch starting with a number is deemed to be a release branch, as such only members of the Release Team or Sysadmins can create new branches starting with a number. 2) The KDE/ prefix in any form or mixture of case is deemed a special reserved prefix, as such only sysadmins can create new branches starting with KDE/. 3) Once these rules can be enforced by filters, then the block and the branch name must give live at the same moment (or in very short order). Obviously these rules would only apply in a hard fashion to the main KDE modules, i.e. the SC, playground and extragear are free to do as they please but following the rules should be recommended. John.
Re: 4.6 branches created in git again
On Sun, Mar 20, 2011 at 10:57, Ian Monroe wrote: > On Sun, Mar 20, 2011 at 09:45, John Tapsell wrote: >> Why do we let people create branches on the main git server anyway? > > Well for feature branches its fine and kind of the point of git. > There's no reason to let non-admins create version branches though. Extragear? Parker
Re: 4.6 branches created in git again
On Sun, Mar 20, 2011 at 10:09, Andreas Hartmetz wrote: > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: >> Can you please be careful and do not create incorrectly 4.6 branches in >> places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) >> >> Ian can you kill them? > > Maybe we can go through with renaming the branches to n.m (without KDE/) > prefix? I think keeping the prefix is the superior option. For kdelibs, kderuntime, kdeworkspace, etc. it really doesn't make any difference, but for something like, say, Konsole the difference is important. If one sees a branch named "4.6" in the Konsole repository, one is likely to assume that it represents Konsole 4.6, when in fact it represents Konsole 2.6 which is part of KDE SC 4.6. Keeping the "KDE/" prefix helps clarify this. Parker
Re: 4.6 branches created in git again
On Sun, Mar 20, 2011 at 09:45, John Tapsell wrote: > Why do we let people create branches on the main git server anyway? > Well for feature branches its fine and kind of the point of git. There's no reason to let non-admins create version branches though. Ian
Re: 4.6 branches created in git again
A Diumenge, 20 de març de 2011, John Tapsell va escriure: > Why do we let people create branches on the main git server anyway? How are you supposed to work on a feature-branch otherwise? Albert
Re: 4.6 branches created in git again
Why do we let people create branches on the main git server anyway?
Re: 4.6 branches created in git again
On Sunday 20 March 2011 15:17:11 Ian Monroe wrote: > On Sun, Mar 20, 2011 at 09:09, Andreas Hartmetz wrote: > > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: > >> Can you please be careful and do not create incorrectly 4.6 branches in > >> places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) > >> > >> Ian can you kill them? > >> > >> Albert > > > > Maybe we can go through with renaming the branches to n.m (without KDE/) > > prefix? > > Some repositories have the prefix, some don't, I think it doesn't make > > sense to have the prefix, and it was decided (by tossing a coin...) that > > the prefix should be removed. > > This would just cause more chaos until we block the creation of > whatever the non-favored naming scheme is. > I'd suggest doing exactly that no matter if the branch names are changed or not.
Re: 4.6 branches created in git again
On Sun, Mar 20, 2011 at 09:09, Andreas Hartmetz wrote: > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: >> Can you please be careful and do not create incorrectly 4.6 branches in >> places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) >> >> Ian can you kill them? >> >> Albert > > Maybe we can go through with renaming the branches to n.m (without KDE/) > prefix? > Some repositories have the prefix, some don't, I think it doesn't make sense > to > have the prefix, and it was decided (by tossing a coin...) that the prefix > should be removed. This would just cause more chaos until we block the creation of whatever the non-favored naming scheme is. Ian
Re: 4.6 branches created in git again
On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: > Can you please be careful and do not create incorrectly 4.6 branches in > places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) > > Ian can you kill them? > > Albert Maybe we can go through with renaming the branches to n.m (without KDE/) prefix? Some repositories have the prefix, some don't, I think it doesn't make sense to have the prefix, and it was decided (by tossing a coin...) that the prefix should be removed.
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Mittwoch 16 März 2011 schrieb John Layt: > [1] > https://www.linuxfoundation.org/collaborate/workgroups/openprinting/openpr > inting- summit-san-francisco-2011 > [2] > http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonp > rintingdialog Hi, I'm very happy to read that there is work to improve the current printing situation. KDE 3 had a wonderful printing system. It was far from perfect but usable. Unfortunately KDE 4 replaced it with a print dialog that is barely usable. I've looked at the Requirements page and started the dialog application. I have some comments and questions: - My biggest wish for a printing dialog is that the preview exactly matches the output. All current print dialogs that I know on linux have the problem that the output is not really predictible if one goes away from the default: printing A4 portrait to an A4 portrait printer. Often one has to try several options to get the desired result or one finally fails. Options that often cause problems are landscape/portrait the size of the media, or multiple pages printing. - The choice of the output paper size and tray should be more prominent. I have one printer where I can find the paper size only in the General tab at the last position of 50 options. - There should be visual feedback how the document applies to the paper. What happens if I print an A4 document and select an A5 paper? How can I specify that the document has to be shrunk to fit? - Is it possible let the dialog shrink the document by a given percentage and to align the document on the paper to have more empty space on the left for a hole-puncher - Is it possible to print an A5 document on A4 paper centered with optional with crop marks at the border? - Will the applications be able to change the document and send a new preview as soon as the options change? - For duplex printing I would like to see a left and right page or top and down page side by side in the preview. - If one prints more than one document page on a paper sheet it should be possible to specify the horizontal and vertical gaps. - The preview should optionally show the media borders, the printable area borders and the document borders on the media. - One advanced option I would like to see: I do not know of any duplex printer that is able to print the front and back page such that for example crop marks exactly match. Often there is an offset one has to apply. It would be nice if one could do this independently for the front and back page in the dialog. Christoph Bartoschek
Re: Top 15 Mailinglists with messages in moderation
On Sunday 20 Mar 2011 13:09:33 Tom Albers wrote: > I've deleted kde-print mailinglist and made John the admin of > kde-print-devel. Password sent in private mail. > > Thanks both! > > Best, Thanks Tom! And many thanks to Cristian for his years of service as moderator, it's appreciated. John.
4.6 branches created in git again
Can you please be careful and do not create incorrectly 4.6 branches in places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) Ian can you kill them? Albert
Re: Top 15 Mailinglists with messages in moderation
Hi, - Original Message - > On March 10, 2011 12:49:16 John Layt wrote: > > I've offered previously to mod those lists, I'd be happy to take > > them on > > now. I think I also previously said we can get rid of the kde-print > > list, > > it's had about 5 mails in the 18 months so I don't think it will be > > missed. I'd rather keep the devel list going for bug triage, and I > > will > > have news about possible new development work on printing in the > > near > > future for which the list may be useful. > > > > Tom, from my part, I believe it is indeed better to go with John's > suggestions. While being there, removing my contact from the admins of > kde- > print-devel ml would be very much appreciated. > > Thanks a lot. > > -- > Cristian Tibirna > KDE developer .. tibi...@kde.org .. http://www.kde.org I've deleted kde-print mailinglist and made John the admin of kde-print-devel. Password sent in private mail. Thanks both! Best, -- Tom Albers KDE Sysadmin
