[yast-devel] New UI Widget -- Idea for Qt and GTK+ interfaces

Hi, When YaST developer or designer are designing the YaST dialogs, they need to define some relative sizes between widgets. Unfortunately, the worst cases cannot be expected and we usually ignore them. Please, see the attachment in this mail. The 'Repository Description' is always replaced with a new one when some other repository is selected in the 'List of Repositories'. The worst case is that there fifty repositories in the 'List of Repositories' but most of the descriptions need thirty lines in the 'Repository Description'. Please, don't write that it would be a _wrong description_, such cases just happen time to time. My idea of a solution would be a user-controllable slider in UI - a new widget for graphical UI. Users could then themselves decide what is more important for them if the data don't fit the UI because screen is not inflatable ;) I'd like to ask YaST developers whether they feel this is worth a feature request and whether it makes even sense to want it. I know that both Qt and GTK+ could implement it but I don't have any idea how difficult would it be. Please, before writing "wrong UI design", "wrong data" ... think about that a few seconds :) If you always wanted such UI feature, write it too ;) Rather think about the advantages of it first :) Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

Please, see the attachment in this mail. The 'Repository Description' is always replaced with a new one when some other repository is selected in the 'List of Repositories'. The worst case is that there fifty repositories in the 'List of Repositories' but most of the descriptions need thirty lines in the 'Repository Description'. Please, don't write that it would be a _wrong description_, such cases just happen time to time.
Repository should not appear in any program texts. Read the style guide. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Rebecca Walter wrote:
Please, see the attachment in this mail. The 'Repository Description' is always replaced with a new one when some other repository is selected in the 'List of Repositories'. The worst case is that there fifty repositories in the 'List of Repositories' but most of the descriptions need thirty lines in the 'Repository Description'. Please, don't write that it would be a _wrong description_, such cases just happen time to time.
Repository should not appear in any program texts. Read the style guide.
Which style guide? http://www.google.com/search?q=style+guide+novell http://www.google.com/search?q=style+guide+novell+program+texts BTW: It seems that new zypper uses "Repository" just everywhere. L.

Which style guide?
http://www.google.com/search?q=style+guide+novell http://www.google.com/search?q=style+guide+novell+program+texts
BTW: It seems that new zypper uses "Repository" just everywhere.
The OFFICIAL one. http://developer.novell.com/wiki/index.php/Opensuse-style Better get fixing zypper. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Rebecca Walter wrote:
Which style guide?
http://www.google.com/search?q=style+guide+novell http://www.google.com/search?q=style+guide+novell+program+texts
BTW: It seems that new zypper uses "Repository" just everywhere.
The OFFICIAL one.
http://developer.novell.com/wiki/index.php/Opensuse-style
Better get fixing zypper.
http://forgeftp.novell.com/opensuse-style/.html/documentation/sec.term.html _installation source_ * correct term for valid sources of installation data for SUSE Linux and openSUSE; when reasonable, mention that _online repositories_ that are valid installation sources are available Those from my screen-shot are only on-line repositories :) I'm afraid that YaST/ZMD/Libzypp/Whatever haven't decided which term we are going to use yet (I mean - our managers). L.

Lukas Ocilka wrote:
Better get fixing zypper.
http://forgeftp.novell.com/opensuse-style/.html/documentation/sec.term.html
_installation source_ * correct term for valid sources of installation data for SUSE Linux and openSUSE; when reasonable, mention that _online repositories_ that are valid installation sources are available
Those from my screen-shot are only on-line repositories :)
I'm afraid that YaST/ZMD/Libzypp/Whatever haven't decided which term we are going to use yet (I mean - our managers).
Anyway, I've changed all text mentioning 'repositories' in that YaST client but I'm afraid it doesn't help much. There are and still will be a lot of "repositories" inside YaST and other applications. L.

* Lukas Ocilka <lukas.ocilka@suse.cz> [Jun 19. 2007 16:23]:
Those from my screen-shot are only on-line repositories :)
I'm afraid that YaST/ZMD/Libzypp/Whatever haven't decided which term we are going to use yet (I mean - our managers).
The term 'repository' is used internally in order to stop the confusion esp. with source packages. Feedback from the community also indicates that 'repository' is a preferred term. Moving forward, we will try to harmonize such names for all products (OpenSuSE and SuSE Linux) and other Novell applications for systems management. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaus Kaempf wrote:
* Lukas Ocilka <lukas.ocilka@suse.cz> [Jun 19. 2007 16:23]:
Those from my screen-shot are only on-line repositories :)
I'm afraid that YaST/ZMD/Libzypp/Whatever haven't decided which term we are going to use yet (I mean - our managers).
The term 'repository' is used internally in order to stop the confusion esp. with source packages. Feedback from the community also indicates that 'repository' is a preferred term.
It's even much simpler than that: "repository" is the only correct technical term. Period. Rebecca, just have a look at how other Linux distributions have been calling those things since many years. I often have to translate "installation sources" as "repository" to new SUSE users (well at least people who have used other distros), sort of: A: add it to "installation sources" in yast B: to .. what ? A: "installation sources" = "repositories" B: ah, ok, repository Really, it's "repository", and anything else is confusing. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGeDARr3NMWliFcXcRAgnwAJ9ACFeC8VH3pd+k1w4kww748FQkMwCgi7R5 EfbqBKkQ3YNohUUZnmj2aAA= =Z4SE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

It's even much simpler than that: "repository" is the only correct technical term. Period.
Rebecca, just have a look at how other Linux distributions have been calling those things since many years.
If you think this is a discussion, you misunderstood something. This is decided as part of the opensuse-style project that was announced months ago. Discussion is already closed on this item. Installation Source is the only term allowed in program texts so development might as well start fixing it. If you had an interest in terminology, you should have paid attention to the announcement. 10.3 is expected to be a transitional release while the official terminology is implemented. After 10.3, any variation in SUSE developed programs and manuals will be considered a bug. Sincerely, Rebecca Walter English Language Consultant and Style Guide Maintainer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 20/06/07, Rebecca Walter <rwalter@suse.de> wrote:
It's even much simpler than that: "repository" is the only correct technical term. Period.
Rebecca, just have a look at how other Linux distributions have been calling those things since many years.
If you think this is a discussion, you misunderstood something. This is decided as part of the opensuse-style project that was announced months ago. Discussion is already closed on this item. Installation Source is the only term allowed in program texts so development might as well start fixing it.
As far as I was aware this was only announced on the opensuse-doc mailing list, without consulting those whom it affects. Could you summarise the reasons behind choosing installation source, which from my research is: - The least used term in SUSE application strings (behind catalogue, repository). So more work to start using it. - Not used by any other distributions other than SUSE, so confuses users coming from them. - Less favoured by those affected by the change. - Technically incorrect.
If you had an interest in terminology, you should have paid attention to the announcement.
Equally you could have announced it to the developers, not just the documentors, who have different goals. I think everyone agrees we need consistent nomenclature, but there is no need to get aggressive when people don't understand the reasoning behind the style guide. _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Wednesday 20 June 2007 10:24, Benji Weber wrote:
On 20/06/07, Rebecca Walter <rwalter@suse.de> wrote:
It's even much simpler than that: "repository" is the only correct technical term. Period.
Rebecca, just have a look at how other Linux distributions have been calling those things since many years.
If you think this is a discussion, you misunderstood something. This is decided as part of the opensuse-style project that was announced months ago. Discussion is already closed on this item. Installation Source is the only term allowed in program texts so development might as well start fixing it.
As far as I was aware this was only announced on the opensuse-doc mailing list, without consulting those whom it affects. Could you summarise the reasons behind choosing installation source, which from my research is:
- The least used term in SUSE application strings (behind catalogue, repository). So more work to start using it. - Not used by any other distributions other than SUSE, so confuses users coming from them. - Less favoured by those affected by the change. - Technically incorrect.
If you had an interest in terminology, you should have paid attention to the announcement.
Equally you could have announced it to the developers, not just the documentors, who have different goals.
I think everyone agrees we need consistent nomenclature, but there is no need to get aggressive when people don't understand the reasoning behind the style guide.
The reasoning is explained on the mailing list. I can't announce these decisions all over the place. Developers are expected to check for new style guides regularly. Internal people, like Lukas and Klaus, were well aware of the project. They should be following it without discussion. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Rebecca Walter wrote:
I think everyone agrees we need consistent nomenclature, but there is no need to get aggressive when people don't understand the reasoning behind the style guide.
The reasoning is explained on the mailing list. I can't announce these decisions all over the place. Developers are expected to check for new style guides regularly.
Internal people, like Lukas and Klaus, were well aware of the project. They should be following it without discussion.
I'm sorry but you can't blame me or Klaus for not following any 'Style Guide' discussion. Nobody invited me (nor Klaus ?) to that discussion. We still have our old YaST (Text) Style Guide in our YaST documentation written by yourself: http://forgeftp.novell.com/yast/doc/SL10.2/styleguide/index.html Moreover, you can expect that developers would check any style guide regularly, they have others task to do. Every important change needs to be announced directly to them. Additionally, in such cases, like unification of "repositories, installation sources, ..." is, you need to assign to that task to follow the discussion and make everybody implement the needed changes. * Nobody has been assigned to such task so far * Management doesn't seem to have it decided yet L.

I'm sorry but you can't blame me or Klaus for not following any 'Style Guide' discussion. Nobody invited me (nor Klaus ?) to that discussion. We still have our old YaST (Text) Style Guide in our YaST documentation written by yourself: http://forgeftp.novell.com/yast/doc/SL10.2/styleguide/index.html
Everyone was invited. The project was announced both internally and externally through the appropriate channels. It isn't my fault if you chose to ignore that post.
Moreover, you can expect that developers would check any style guide regularly, they have others task to do. Every important change needs to be announced directly to them.
I have other tasks to do too. I can't run around telling everyone. I tried to post the change to results but the list owner rejected the message and hasn't responded to my follow-up e-mails about it. I keep tabs on this list. This is the first violation I've seen discussed. So I promptly responded and reminded you of it. What more do you expect?
Additionally, in such cases, like unification of "repositories, installation sources, ..." is, you need to assign to that task to follow the discussion and make everybody implement the needed changes. * Nobody has been assigned to such task so far * Management doesn't seem to have it decided yet
It is always your job to follow the style guide. Management has supported creation of the project and is aware of the discussion and the decision. I'm following the guidelines for project discussion decided in conjunction with management. I'm doing my job to the best of my ability. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Qua, 2007-06-20 às 11:27 +0200, Rebecca Walter escreveu:
Moreover, you can expect that developers would check any style guide regularly, they have others task to do. Every important change needs to be announced directly to them.
I have other tasks to do too. I can't run around telling everyone. I tried to post the change to results but the list owner rejected the message and
Are you referring to an open mailing list, (opensuse-*)? AFAIK those are not moderated. You need however to be subscribed to them in order to be able to post there. You would get some automatic reply otherwise... Could this explain what happened? Btw, in yast-gtk's package selector we have a sources table, which is labeled as "Packages Sources". :/ "Installation Source" makes so little sense that the style-guide uses the term "repository" in its definition. :D Cheers, Ricardo
hasn't responded to my follow-up e-mails about it. I keep tabs on this list. This is the first violation I've seen discussed. So I promptly responded and reminded you of it. What more do you expect?
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 6/20/07, Rebecca Walter <rwalter@suse.de> wrote:
The reasoning is explained on the mailing list. I can't announce these decisions all over the place.
Why ever not? It only consists of adding a few more email addresses in that "To:". Really would be good to get things like this through at least the -project@ list; though having the original discussion on opensuse@ might have been enlightening since it's got even more of a general user-base. With regard to the external discussion on opensuse-doc, didn't almost everyone prefer the term repository? I only recall a couple of persons preferring the term "Installation Source", but perhaps I'm mistaken? Kind thoughts, -- Francis Giannaros http://francis.giannaros.org -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, On Jun 20 09:32 Rebecca Walter wrote (shortened):
Pascal Bleser <pascal.bleser@skynet.be> wrote:
It's even much simpler than that: "repository" is the only correct technical term. Period.
Rebecca, just have a look at how other Linux distributions have been calling those things since many years.
If you think this is a discussion, you misunderstood something. This is decided as part of the opensuse-style project that was announced months ago. Discussion is already closed on this item. Installation Source is the only term allowed in program texts so development might as well start fixing it.
If you had an interest in terminology, you should have paid attention to the announcement.
10.3 is expected to be a transitional release while the official terminology is implemented. After 10.3, any variation in SUSE developed programs and manuals will be considered a bug.
Rebecca, is it perhaps you who terrible misunderstand something here? Perhaps you missed to take into account that YaST development happens now via a public accessible mailing list and therefore it might seem arrogant how you teach community members what they must do according to your internal guidelines and announcements. I think that we should definitely appreciate any reasonable input regarding YaST development from community members because otherwise we should make YaST non-free software with a non-public YaST development mailing list. Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Wednesday 20 June 2007 12:09, Johannes Meixner wrote:
Perhaps you missed to take into account that YaST development happens now via a public accessible mailing list and therefore it might seem arrogant how you teach community members what they must do according to your internal guidelines and announcements.
My apologies to the community for poorly phrasing my original post in response to a community member. I do appreciate your interest in YaST and our terminology, but I cannot and will not reopen the discussion at this time. If you are interested in participating in future dicussions of other topics, you want to check out the project page (http://developer.novell.com/wiki/index.php/Opensuse-style) and sign up to participate. My intention was not to open any discussion here but to remind the developers of the style guide and that they are expected to follow it. Thank you Johannes for drawing my attention to how my post was understood. It was not my intention to offend the community. Sincerely, Rebecca -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Wednesday 20 June 2007 09:32:04 Rebecca Walter wrote:
If you think this is a discussion, you misunderstood something. This is decided as part of the opensuse-style project that was announced months ago. Discussion is already closed on this item. Installation Source is the only term allowed in program texts so development might as well start fixing it.
I don't think style guides should be designed without asking the users. We are changing to repository because: - users wants it - all other programs use it That is harder to fix than fixing the style guide. Also: - In opensource, discussions are never closed -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Wednesday 20 June 2007 09:32:04 Rebecca Walter wrote:
Rebecca, just have a look at how other Linux distributions have been calling those things since many years.
If you think this is a discussion, you misunderstood something. This is decided as part of the opensuse-style project that was announced months ago. Discussion is already closed on this item. Installation Source is the only term allowed in program texts so development might as well start fixing it.
And did anyone look at other distros by then? If the discussion is "closed", is it possible to know the criteria used? Who from the package management people was consulted/asked? You can't expect all people to follow this project, it should be the other way around, and the people in the project should invite the right people to decide on one specific term, otherwise, one expert from each of the hundred of knowledge areas would need to be in the style guide project.
10.3 is expected to be a transitional release while the official terminology is implemented. After 10.3, any variation in SUSE developed programs and manuals will be considered a bug.
Then we are at time to fix the style guide, from the moment a term is decided. The style guide is in a wiki after all, not on stone tablets. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Pascal Bleser wrote:
Klaus Kaempf wrote:
* Lukas Ocilka <lukas.ocilka@suse.cz> [Jun 19. 2007 16:23]:
Those from my screen-shot are only on-line repositories :)
I'm afraid that YaST/ZMD/Libzypp/Whatever haven't decided which term we are going to use yet (I mean - our managers). The term 'repository' is used internally in order to stop the confusion esp. with source packages. Feedback from the community also indicates that 'repository' is a preferred term.
It's even much simpler than that: "repository" is the only correct technical term. Period.
Rebecca, just have a look at how other Linux distributions have been calling those things since many years.
I often have to translate "installation sources" as "repository" to new SUSE users (well at least people who have used other distros), sort of: A: add it to "installation sources" in yast B: to .. what ? A: "installation sources" = "repositories" B: ah, ok, repository
Really, it's "repository", and anything else is confusing.
I have to agree with Pascal here. Not only have other distros been using the term "repository" for years, but it is part of published standards. http://www.dmtf.org/standards/published_documents/DSP1023.pdf "Note: Representing Available Software is different from representing a software repository, which would be modeled in a different way and specializes in showing the software that is available to all the systems that can access the repository. See the Software Repository Profile (DSP1032)." Unfortunately DSP1032 seems to not be published yet. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, On Jun 21 16:29 Bart Whiteley wrote:
Pascal Bleser wrote:
Klaus Kaempf wrote:
* Lukas Ocilka <lukas.ocilka@suse.cz> [Jun 19. 2007 16:23]:
Those from my screen-shot are only on-line repositories :)
I'm afraid that YaST/ZMD/Libzypp/Whatever haven't decided which term we are going to use yet (I mean - our managers). The term 'repository' is used internally in order to stop the confusion esp. with source packages. Feedback from the community also indicates that 'repository' is a preferred term.
It's even much simpler than that: "repository" is the only correct technical term. Period.
Rebecca, just have a look at how other Linux distributions have been calling those things since many years.
I often have to translate "installation sources" as "repository" to new SUSE users (well at least people who have used other distros), sort of: A: add it to "installation sources" in yast B: to .. what ? A: "installation sources" = "repositories" B: ah, ok, repository
Really, it's "repository", and anything else is confusing.
I have to agree with Pascal here. Not only have other distros been using the term "repository" for years, but it is part of published standards.
http://www.dmtf.org/standards/published_documents/DSP1023.pdf
"Note: Representing Available Software is different from representing a software repository, which would be modeled in a different way and specializes in showing the software that is available to all the systems that can access the repository. See the Software Repository Profile (DSP1032)."
Unfortunately DSP1032 seems to not be published yet.
The real problem is not what the most correct technical term is. The real problem is how to make it clear to all users (i.e. experienced and unexperienced users) what is meant (i.e. what the actual meaning - the idea - behind the term is). Usually technical terms get introduced by whoever invents the idea behind it. On the one hand we all would like to have unique technical terms but on the other hand (i.e. in reality) we must somehow deal with multiple technical terms for the same idea behind it because often there is more than one inventor of the idea (and often different inventors use intentionally different terms for the same idea to differentiate between each other). Of course we (i.e. Novell/Suse) also invent such terms. Unfortunately it seems that we also do not always accept existing technical terms which had been introduced by whoever invented the idea behind it but instead we use our own terms. Of coursee there have been reasons at the time in the past when it happened and now we must somehow deal with the situation. I know that this doesn't help to solve the current problem. But it should indicate that it might be totally impossible to get unique technical terms and then we may simply have to accept multiple technical terms for the same idea. But then we should at least aviod to add even more confusion if we created our own new technical term for an existing idea. A suggestion to deal with multiple technical terms: If there are multiple technical terms for the same idea, choose the technical term which is easiest to understand by an unexperienced user. For example I run into a long discussion with our translators regarding "backend" in SANE. Furthermore I had ugly help texts in YaST which tried to explain what "backend" means. I myself was so used to use "backend" that my mind was somehow blocked to see that "backend" is just the technical term of the SANE project for what the unexperienced user would call a "driver" ("the piece of software which does the hardware-dependent stuff"). I changed "backend" to "driver" in all texts in YaST which are visible for the user and the problem was immediately solved for both our translators and for all users because the experienced user also understands what "driver" means. Note that I wrote "choose" - i.e. do not create a new term but choose from the existing technical terms. Note that I wrote "by an unexperienced user" - i.e. if one technical term is easier to understand by unexperienced users (in particular if a term is already known by unexperienced users), choose this one even if another technical term is more correct. For example prefer "firewall" over "package filter" even if the "firewall" is actually only a "package filter". Note that I wrote "technical term" - i.e. do not replace a technical term by a non-technical platitude and do not replace a meaningful technical term by a too simple technical word. For example "printer description file" is unfortunately often replaced by "driver" and users are confused because installing such a kind of "driver" does not make their printer work (because a "driver" does the hardware-dependent stuff but a "printer description file" only describes it). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

I have to agree with Pascal here. Not only have other distros been using the term "repository" for years, but it is part of published standards.
http://www.dmtf.org/standards/published_documents/DSP1023.pdf
"Note: Representing Available Software is different from representing a software repository, which would be modeled in a different way and specializes in showing the software that is available to all the systems that can access the repository. See the Software Repository Profile (DSP1032)."
Unfortunately DSP1032 seems to not be published yet.
You're the first person to give me anything concrete that supports repository. Thank you. Unfortunately, it has no definition or further explanation of what it considers a repository. It still can't really help in this situation. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 22/06/07, Rebecca Walter <rwalter@suse.de> wrote:
You're the first person to give me anything concrete that supports repository. Thank you. Unfortunately, it has no definition or further explanation of what it considers a repository. It still can't really help in this situation.
Unlike the term "installation source" (which is a term invented for this specific usage, people would have to learn what it means). "Repository" is a common English word that is used for exactly this purpose. To quote the Oxford English Dictionary a repository is: 1a. A vessel, receptacle, chamber, etc., in which things are or may be placed, deposited, or stored. 1b. A place, room, or building, in which specimens, curiosities, or works of art are collected; a museum. 1c. A place where things are kept or offered for sale; a warehouse, store, shop, mart. 3. A place or thing within which something immaterial is thought of as deposited or contained. 4. A part or place in which something is accumulated or exists in quantities. Replace the generic "thing" with the specific "software" in any of these definitions and it fits the usage. I'm not sure we can justify creating a new term when one already exists in English. _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, On Jun 22 08:53 Benji Weber wrote:
Unlike the term "installation source" (which is a term invented for this specific usage, people would have to learn what it means). "Repository" is a common English word that is used for exactly this purpose. To quote the Oxford English Dictionary a repository is:
1a. A vessel, receptacle, chamber, etc., in which things are or may be placed, deposited, or stored.
1b. A place, room, or building, in which specimens, curiosities, or works of art are collected; a museum.
1c. A place where things are kept or offered for sale; a warehouse, store, shop, mart.
3. A place or thing within which something immaterial is thought of as deposited or contained.
4. A part or place in which something is accumulated or exists in quantities.
Replace the generic "thing" with the specific "software" in any of these definitions and it fits the usage. I'm not sure we can justify creating a new term when one already exists in English.
I am no native English speaker but with the above definition "repository" seems to be an easy but meaningless word. It seems it is "anything where software can be" so that also my harddisk is a "repository" and also each of its partitions and any download area wherever in the Internet for whatever software, all are simply "repositories". But as far as I understand we are only interested in the particular "repositories" which can be used to "install software for openSUSE" and then those "repositories" are sources from which one can install software i.e. "installation sources". Or do I misunderstand it completely? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Friday 22 June 2007 09:53:54 Benji Weber wrote:
Unlike the term "installation source" (which is a term invented for this specific usage, people would have to learn what it means). "Repository" is a common English word that is used for exactly this purpose. To quote the Oxford English Dictionary a repository is:
Similar in spanish: repositorio. (Del lat. repositorĭum, armario, alacena). 1. m. Lugar donde se guarda algo. (Place where you store something). Still, I find Bart's argument the most powerful one. Widely used and present in published standards. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg hGF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Duncan Mac-Vicar Prett wrote:
On Friday 22 June 2007 09:53:54 Benji Weber wrote:
Unlike the term "installation source" (which is a term invented for this specific usage, people would have to learn what it means). "Repository" is a common English word that is used for exactly this purpose. To quote the Oxford English Dictionary a repository is:
Similar in spanish: repositorio. (Del lat. repositorĭum, armario, alacena). 1. m. Lugar donde se guarda algo.
(Place where you store something).
Still, I find Bart's argument the most powerful one. Widely used and present in published standards Let's see what else we can find. http://en.wikipedia.org/wiki/Software_repository (no, I didn't just write it). 'man apt-get': two instances of "repository" 'man yum': two instances of "repository" 'man createrepo': five instances of "repository" (not to mention the name of the command, and the name of the metadata it creates ("repomd").
When you go to http://software.opensuse.org/download, and select a repository (see, it just sounds natural), you'll see a "repodata" folder, and a "<project>.repo" file. In the DMTF Server Management Working Group email archives, there are discussions about the yet-to-be-published Software Repository Profile, including a slide deck called "Software Repository Profile Requirements" -- 14 instances of "repository" in 4 slides. Unfortunately these discussions are password protected, so I can't share the documents on this public list. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

I'm sorry everyone but I have just been informed by management that we're to use catalog. So there is really no point making an effort to convince me of anything. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 22/06/07, Rebecca Walter <rwalter@suse.de> wrote:
I'm sorry everyone but I have just been informed by management that we're to use catalog. So there is really no point making an effort to convince me of anything.
Of course one problem with catalogue is that Americans can't spell it. _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Den Friday 22 June 2007 19:49:28 skrev Benji Weber:
On 22/06/07, Rebecca Walter <rwalter@suse.de> wrote:
I'm sorry everyone but I have just been informed by management that we're to use catalog. So there is really no point making an effort to convince me of anything.
Of course one problem with catalogue is that Americans can't spell it.
One of many... "management" doesn't see any need to justify that decision I guess? Did anybody _at all_ want catalogue in any of the discussions so far? here? on -doc? Catalogue has no benefits at all.. it's not the "community standard" like repo.. and it's not informative to n00bs and coherent with SUSE tradition like inst-source.. it just plain sucks.. geez... /me wishes "management" would join the ml, or stay out of our business.. or at least be receptive to reason.. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

One of many...
"management" doesn't see any need to justify that decision I guess?
Did anybody _at all_ want catalogue in any of the discussions so far? here? on -doc?
Catalogue has no benefits at all.. it's not the "community standard" like repo.. and it's not informative to n00bs and coherent with SUSE tradition like inst-source.. it just plain sucks.. geez...
/me wishes "management" would join the ml, or stay out of our business.. or at least be receptive to reason..
I'm sorry, but I don't think I'm authorized to say anything more. It isn't certain the decision is final, but I had to have something so I could work on software proofreading next week. So this is at least management's working decision for now. Hopefully someone with more authority in the company will address your concerns in the near future. I just wanted to let you know so no one continued putting effort trying to convince me of anything as the decision is not mine. I really hate for the community to waste its energy. Sincerely, Rebecca -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

I'm sorry, but I don't think I'm authorized to say anything more. It isn't certain the decision is final, but I had to have something so I could work on software proofreading next week. So this is at least management's working decision for now.
Could you summarize why if most of the people interested in that doensn't want to? Below a comment Ive wrote about it: Hi Let me summarize the problem, and I want to make the problem explicit and crystal clear. In one side, Rebecca and his manager says it wont be repository just because they said so, no argumentation. In the other side, all the other distros, community, users and developers want to use I can only think of one word in this situation: truculence. Truculence and lack of will in make things happen, make things correct. Make things work and make the best for linux. And who is using this truculence? Novell is using this truculence. Rebeca saying that its our problem, fix everything else and invert Earth's rotation but its our problem is a pure truculent answer. It is clear the lack of tune with the rest of the linux community, not to mentio pure arrogant position. Last time you made people swallow the "management preference" of Novell we ended with an unusable 10.1. Lesson was not learnt? All I can say is that the management is once again being incompetent for the task of managing the building of a Linux distribution with community aid, and the lack of understanding in working together and addressing all sides needs and wishes. As Duncan said, I can tell its much easier to simply change the guideline to something more sensible than invert Earth's rotation. Sorry if I forgot to address some relevant points (for example how it was chosen that word instead of repository) but it is clear Novell people specially amangement created a problem and they are being incompetent to solve it. All that said, and seeing a dozen of emails in the discussion (if there is one, cause Ive heard previously that there wasnt), I would like to know what is going to be the decision on this? That we should simply use the word they want it to be swallowed by everyone, or if there is going to be a discussion on this. Marcio Ferreira --- Druid -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rebecca Walter wrote:
I'm sorry everyone but I have just been informed by management that we're to use catalog. So there is really no point making an effort to convince me of anything.
I would like to know who "management" is, on this topic. Pretty much everyone agrees "repository" is the best term (*), it's the term used on every Linux distribution since many years, and it's the term that instantly makes sense for any experienced Linux user (even on other distros). (Rebecca, I'm not addressing this to you specifically, nor "attacking" you by any means, even if your previous replies were anything but polite) (*) Johannes: I really disagree on using what's the easiest for unexperienced users in this case: to all of them, it is going to be a new concept anyway. Unexperienced and/or Windows converts (ok, pleonasm) are definitely not used to package management, dependencies, repositories, etc..., so they will have to learn what it is anyway. Never mind whether it's "repository", "installation source", "catalog", it will be new to them. On the other hand, for experienced users, using something else than "repository" only sounds pathetic. But let's get to the point of what's actually happening here. It's not just that the "management" is disregarding the opinion of its skilled technical employees -- I mean, we're all used to that, everywhere, aren't we ? -- they are also disregarding the input of the community... although, well, no one really asked us in the first place. This may sound ridiculous and exaggerated to some (or many?) but it's a question of attitude and will. So... do they want to work with us or not? Please give us a few names who those "management" persons are in order to confront them with the reality of what they're currently doing, or please pass the message to them. Management or marketing (i.e. non-technical) people taking decisions on technical matters ignoring the opinion of technical people is a terrible thing to do (in any business, not just for Novell). They should be enlightened that the consequences are anything but negligible, even if they're going to say "ah cmooooon, it's just a word"... It isn't. It's about whether our motivation, our input and our spare time spent on this project is taken into account and useful at all. Exaggerating ? possibly. It depends who that "management" is. Especially if it's Novell (as in "not ex-SUSE"). Thanks for reading. - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGfCLyr3NMWliFcXcRAlrDAKCX4RE9Empm2erKvxfUvBM6NEkFpgCfUXPz cnAWRffTxmskEcNc87uH8wc= =fksv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

The term 'repository' is used internally in order to stop the confusion esp. with source packages. Feedback from the community also indicates that 'repository' is a preferred term.
Moving forward, we will try to harmonize such names for all products (OpenSuSE and SuSE Linux) and other Novell applications for systems management.
Terminology is decided by the openSUSE style project and has already been decided. Installation Source is the correct term and repository MAY NOT appear in the program UIs. The project is supported by management and was announced. The decision is final. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Rebecca Walter <rwalter@suse.de> [2007-06-20 09:25]:
The project is supported by management and was announced. The decision is final.
Is there a URL for this project? Thanks, Bernhard -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Wednesday 20 June 2007 09:33, Bernhard Walle wrote:
* Rebecca Walter <rwalter@suse.de> [2007-06-20 09:25]:
The project is supported by management and was announced. The decision is final.
Is there a URL for this project?
Thanks, Bernhard
Again: http://developer.novell.com/wiki/index.php/Opensuse-style -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hi Lukas, +++ Lukas Ocilka [19/06/07 15:49 +0200]:
Hi,
When YaST developer or designer are designing the YaST dialogs, they need to define some relative sizes between widgets. Unfortunately, the worst cases cannot be expected and we usually ignore them.
Please, see the attachment in this mail. The 'Repository Description' is always replaced with a new one when some other repository is selected in the 'List of Repositories'. The worst case is that there fifty repositories in the 'List of Repositories' but most of the descriptions need thirty lines in the 'Repository Description'. Please, don't write that it would be a _wrong description_, such cases just happen time to time.
My idea of a solution would be a user-controllable slider in UI - a new widget for graphical UI. Users could then themselves decide what is more important for them if the data don't fit the UI because screen is not inflatable ;)
I'd like to ask YaST developers whether they feel this is worth a feature request and whether it makes even sense to want it. I know that both Qt and GTK+ could implement it but I don't have any idea how difficult would it be.
Please, before writing "wrong UI design", "wrong data" ... think about that a few seconds :) If you always wanted such UI feature, write it too ;) Rather think about the advantages of it first :)
Thanks & Bye Lukas
--
Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
I like this UI element (split window slider) in interfaces. My only concern would be how you enable an ncurses equivalent. This feature is nice for dynamically changing the UI to suit the data displayed - but without an ncurses option will you end up with UI's that are very hard to use (or unusable) from text mode. -dom

Dominic Reynolds wrote:
Hi Lukas,
I like this UI element (split window slider) in interfaces. My only concern would be how you enable an ncurses equivalent. This feature is nice for dynamically changing the UI to suit the data displayed - but without an ncurses option will you end up with UI's that are very hard to use (or unusable) from text mode.
Honestly, how do we do it now? We define a dialog with these layout widgets as a "default": * HBox, VBox * HSpacing, VSpacing * Left, Right, ... Bottom * HWegiht, VWeight * HStretch, VStretch ... A new widget would be just a helper when the "default" fails for some cases. It should help Qt and GTK+ interface, it shouldn't kill ncurses that can't support it (could only by some ugly hack). L.

+++ Lukas Ocilka [19/06/07 16:55 +0200]:
Dominic Reynolds wrote:
Hi Lukas,
I like this UI element (split window slider) in interfaces. My only concern would be how you enable an ncurses equivalent. This feature is nice for dynamically changing the UI to suit the data displayed - but without an ncurses option will you end up with UI's that are very hard to use (or unusable) from text mode.
Honestly, how do we do it now? We define a dialog with these layout widgets as a "default": * HBox, VBox * HSpacing, VSpacing * Left, Right, ... Bottom * HWegiht, VWeight * HStretch, VStretch ...
A new widget would be just a helper when the "default" fails for some cases. It should help Qt and GTK+ interface, it shouldn't kill ncurses that can't support it (could only by some ugly hack).
Ah ok. I didn't understand that this would be a widget automagically added to a form in the case default layout rules couldn't generate a standard UI. From bubli's post I guess there are a number of widgets that require you to check the UI that you are in and code accordingly. Whats the best way to be aware of QT only widgets so that when you are developing you know that for ncurses support you need special handling? Is there a naming convention for them? thanks, dom
L.

Hi Dom :-)
From bubli's post I guess there are a number of widgets that require you to check the UI that you are in and code accordingly.
Whats the best way to be aware of QT only widgets so that when you are developing you know that for ncurses support you need special handling? Is there a naming convention for them?
I guess this is a complete list of Qt-only widgets (don't know what is the status of these in Gtk, though) that are definitely not supported in ncurses: http://forgeftp.novell.com/yast/doc/SL10.2/tdg/YUI_special_widgets.html B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

Qua, 2007-06-20 às 09:02 +0200, Katarina Machalkova escreveu:
Hi Dom :-)
From bubli's post I guess there are a number of widgets that require you to check the UI that you are in and code accordingly.
Whats the best way to be aware of QT only widgets so that when you are developing you know that for ncurses support you need special handling? Is there a naming convention for them?
I guess this is a complete list of Qt-only widgets (don't know what is the status of these in Gtk, though) that are definitely not supported in ncurses: http://forgeftp.novell.com/yast/doc/SL10.2/tdg/YUI_special_widgets.html
yast-gtk supports everything. If GTK+ doesn't have a widget that Qt has (like the BarGraph), we can just code it, so it is very unlikely that we won't support something that yast-qt does. There are some noticeable differences in widgets (like the Date), but they are roughly the same size, so it shouldn't affect presentation. The layouting differences may be worth to describe in the documentation though. In any case, to check if a special widget is supported you use UI::doesItSupportWidget(X) (or whatever its called); you don't do a hard check on what interface is being used. Cheers, Ricardo
B.
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, On Jun 20 15:38 Ricardo Cruz wrote (shortened):
Qua, 2007-06-20 às 09:02 +0200, Katarina Machalkova escreveu:
I guess this is a complete list of Qt-only widgets (don't know what is the status of these in Gtk, though) that are definitely not supported in ncurses: http://forgeftp.novell.com/yast/doc/SL10.2/tdg/YUI_special_widgets.html
... In any case, to check if a special widget is supported you use UI::doesItSupportWidget(X) (or whatever its called); you don't do a hard check on what interface is being used.
Perhaps I misunderstand something and perhaps it is a bit off-topic: Is there an automated check which I could apply to YCP sources which tests if a widget is used which does not work o.k. in all underlying UI systems? I noticed some sources of information which widget is supported where (Qt, Gtk, ncurses, whatever else ...). But I am not a hardcore YCP programmer. I neither have the time nor the interest to read continuously whatever sources of information which widgets I can use in YCP so that it works o.k. for all underlying UI systems. I don't want to think about how I could emulate whatever widget for UI "foo" which unfortunately works only for UI "bar". I like to use only widgets that work o.k. for all UIs. If I don't get clear warning messges during "make", the YCP code is o.k. for me. I use tests like y2tool check_ycp src/*.ycp ycpc -qE -M. -I. src/*.ycp but when there are no warnings, it is o.k. for me. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex

On Thursday 21 June 2007 11:45, Johannes Meixner wrote:
Is there an automated check which I could apply to YCP sources which tests if a widget is used which does not work o.k. in all underlying UI systems?
Currently we have no such tool. For those optional widgets, widget documentation clearly says that it's optional (a "special widget"), and that the application has to check for availability with UI::HasSpecialWidget(`FancyWidgetName) before it is used. But I think this is a good suggestion, and it also shouldn't be so hard to implement it. On the tool level, we could write something very simple based on 'grep' (or a little more fancy with Perl) that checks for known names of those optional widgets, and if there is one, if the same source file also contains the appropriate UI::HasSpecialWidget() call with the same widget name. But this can go even further, and I am in the process of refactoring the UI engine anyway. The UI itself can check if the application checked for availability of such an optional widget before it created one, and if the application didn't check, the UI engine could write a warning to the log file. That way, application programmers (at least those who don't ignore all warnings in the logs) would notice even if they use only the UI that has all the optional widgets.
I neither have the time nor the interest to read continuously whatever sources of information which widgets I can use in YCP so that it works o.k. for all underlying UI systems.
Well, if you use a widget, you'll probably look up its documentation anyway where this is spelled out in great detail - both in the reference documentation and in the reference examples. But it sure can't hurt to add more checks. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, On Jun 21 12:14 Stefan Hundhammer wrote (shortened):
For those optional widgets, widget documentation clearly says that it's optional (a "special widget"), and that the application has to check for availability with UI::HasSpecialWidget(`FancyWidgetName) before it is used.
Good! As I didn't notice any such info, I assume I don't use special widgets.
I neither have the time nor the interest to read continuously whatever sources of information which widgets I can use in YCP so that it works o.k. for all underlying UI systems.
Well, if you use a widget, you'll probably look up its documentation anyway
Of course. But usually I read it ony when I use a widget for the first time. When a new UI system comes, I wouldn't check the documentation again if some widgets might no longer be supported for the new UI. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Thursday 21 June 2007 14:09, Johannes Meixner wrote:
When a new UI system comes, I wouldn't check the documentation again if some widgets might no longer be supported for the new UI.
No. That doesn't happen. And if it did, we would announce it loud and clear on very prominent mailing lists, and also grep existing code where it had been used before. You don't have to fear about that. Mandatory widgets are always mandatory. We won't take any of them away. If at all, we might choose to do it the other way and declare optional widgets to be mandatory. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Dominic Reynolds wrote:
Ah ok. I didn't understand that this would be a widget automagically added to a form in the case default layout rules couldn't generate a standard UI.
From bubli's post I guess there are a number of widgets that require you to check the UI that you are in and code accordingly.
Whats the best way to be aware of QT only widgets so that when you are developing you know that for ncurses support you need special handling? Is there a naming convention for them?
Frankly, I thought about more possibilities, but for me, the best would be: * You can use that widget (only) manually. For other cases, layout should behave as it did before. * Ncurses would know but _ignore_ that widget. * GTK+ could but needn't to support it. Example of a simple dialog with two stretchable widgets taking 1/4, resp. 3/4, of the dialog: --- cut --- `VBox ( `VWeight ( 1, some_other_widget (`opt (`vstretch)) ), `VWeight ( 3, some_other_widget (`opt (`vstretch)) ) ) --- cut --- Example of the same dialog with additional splitter: --- cut --- `VBox ( `VWeight ( 1, some_other_widget (`opt (`vstretch)) ), `VSplitter(`opt (`do_we_need_any_options?)), `VWeight ( 3, some_other_widget (`opt (`vstretch)) ) ) --- cut --- That wouldn't need any additional checking for UI support. Yes, there are several Qt-only widgets: http://forgeftp.novell.com/yast/doc/SL10.2/tdg/Book-UIReference.html (IV. Special (optional) widgets) For checking, whether some widget is supported, we use http://forgeftp.novell.com/yast/doc/SL10.2/tdg/YUI_special_widgets_HasSpecia... Nevertheless the documentation seems to be a bit odd :) see how is this used in our source code: if (!UI::HasSpecialWidget (`DumbTab)) if ( ! UI::HasSpecialWidget(`PatternSelector ) UI::HasSpecialWidget(`BarGraph ) ... The best way is to know both, the standard widget set and the optional widget set. I don't think we have any naming convention. L.

Hola!
Example of the same dialog with additional splitter:
--- cut --- `VBox ( `VWeight ( 1, some_other_widget (`opt (`vstretch)) ), `VSplitter(`opt (`do_we_need_any_options?)), `VWeight ( 3, some_other_widget (`opt (`vstretch)) ) ) --- cut ---
Hmm, though I did not went through complete Trolltech Qt documentation, QSplitter works more like Q*Box widget - it is rather a parent widget with several children, separated by splitters. So the code above would possibly look more like: `VSplitter( `SomeWidget(`opt(something)), `OtherWidget(), ) Now user can move the splitters and make child widgets as small or as large as their minimum or maximum defined size B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

On Wed, Jun 20, 2007 at 09:29:08AM +0200, Bubli wrote:
Hola! Hmm, though I did not went through complete Trolltech Qt documentation, QSplitter works more like Q*Box widget - it is rather a parent widget with several children, separated by splitters. So the code above would possibly look more like:
`VSplitter( `SomeWidget(`opt(something)), `OtherWidget(), )
It seems that we cannot introduce a Splitter without all UIs knowing about it. (Or can't we? `VBox( `opt(`splitter), ...)?) But then it should be easy to just fall back to an ordinary Box until we have time to implement the Splitter. And in curses, it would not be particularly easy to handle, but I can imagine navigating to a handle using Tab and then using the arrows. The handle could be (UNICODE warning!): ↔ ↕ like -------- ↕ ---------- or a simple -------- | ---------- -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Czau!
I like this UI element (split window slider) in interfaces. My only concern would be how you enable an ncurses equivalent.
You don't :-( I'm afraid there's no way how to implement slider in y2-ncurses. (n)curses library - which y2-ncurses uses -simply does not offer this form of interfacing with the mouse and I doubt it will ever do so.
This feature is nice for dynamically changing the UI to suit the data displayed - but without an ncurses option will you end up with UI's that are very hard to use (or unusable) from text mode.
Oh well, it would be just another widget supported by 'fancy' UI's and not in text mode. We already have quite some of those (Date, ColoredLabel etc.). If you want to use these, you always need some UI::GetDisplayInfo or UI::HasSpecialWidget workarounds in your code and come up with alternative solution for the text-mode. Some things are just not doable in ncurses, I'm sorry B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

On Tuesday 19 June 2007 16:59, Katarina Machalkova wrote:
This feature is nice for dynamically changing the UI to suit the data displayed - but without an ncurses option will you end up with UI's that are very hard to use (or unusable) from text mode.
Oh well, it would be just another widget supported by 'fancy' UI's and not in text mode. We already have quite some of those (Date, ColoredLabel etc.). If you want to use these, you always need some UI::GetDisplayInfo or UI::HasSpecialWidget workarounds in your code and come up with alternative solution for the text-mode. Some things are just not doable in ncurses, I'm sorry
Could it be just dummy? I mean, it wouldn't be necessary to check UI::GetDisplayInfo just like it is necessary for Date widget which is used for the real presentation of some data, so developer must code ncurses-special replacement. ncurses UI could just ignore it, or apply the default weights (which should new widget require anyway), and leave them fixed.
B.
j -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Tuesday 19 June 2007 15:49, Lukas Ocilka wrote:
When YaST developer or designer are designing the YaST dialogs, they need to define some relative sizes between widgets. Unfortunately, the worst cases cannot be expected and we usually ignore them.
Please, see the attachment in this mail. The 'Repository Description' is always replaced with a new one when some other repository is selected in the 'List of Repositories'. The worst case is that there fifty repositories in the 'List of Repositories' but most of the descriptions need thirty lines in the 'Repository Description'. Please, don't write that it would be a _wrong description_, such cases just happen time to time.
My idea of a solution would be a user-controllable slider in UI - a new widget for graphical UI. Users could then themselves decide what is more important for them if the data don't fit the UI because screen is not inflatable ;)
You mean a "splitter" widget, not a slider, right? Something like that: http://doc.trolltech.com/3.3/qsplitter.html This is something we are already using extensively in the YQPackageSelector, but on the Qt/C++ level. It does have its benefits, but it also comes at a cost. The major benefit is of course that the user is free to resize subwindows so he can get more screen space for things he is interested in at the cost of getting less screen space for other widgets. The real downside of that kind of widget, however, is that it's really hard to specify reasonable initial behaviour. Maybe we could overcome that with weights, so the application could specify to use, say, 30% for one subwindow and 70% for the other. But it would probably mean that there would be no automatic layout calculation to make other widgets fit in their natural size. It would work well for wigets that don't have a natural size to begin with, such as selection boxes, tables, rich text. Others like buttons, combo boxes etc. would very often look very odd -- too large or too small, depending on all the other widgets and the specified weights. Other than that, this shouldn't be so hard to do for the Qt UI, and probably similar for the Gtk UI. But would it also work for NCurses? I have no clue. In general, we probably want to have such a widget (but not for 10.3 - too late). But also in general, needing it is usually an indicator for overcrowded dialogs. It might be worth while to try to figure out another way of presenting the information. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Ter, 2007-06-19 às 16:54 +0200, Stefan Hundhammer escreveu:
On Tuesday 19 June 2007 15:49, Lukas Ocilka wrote:
When YaST developer or designer are designing the YaST dialogs, they need to define some relative sizes between widgets. Unfortunately, the worst cases cannot be expected and we usually ignore them.
Please, see the attachment in this mail. The 'Repository Description' is always replaced with a new one when some other repository is selected in the 'List of Repositories'. The worst case is that there fifty repositories in the 'List of Repositories' but most of the descriptions need thirty lines in the 'Repository Description'. Please, don't write that it would be a _wrong description_, such cases just happen time to time.
My idea of a solution would be a user-controllable slider in UI - a new widget for graphical UI. Users could then themselves decide what is more important for them if the data don't fit the UI because screen is not inflatable ;)
You mean a "splitter" widget, not a slider, right? Something like that:
http://doc.trolltech.com/3.3/qsplitter.html
This is something we are already using extensively in the YQPackageSelector, but on the Qt/C++ level.
It does have its benefits, but it also comes at a cost. The major benefit is of course that the user is free to resize subwindows so he can get more screen space for things he is interested in at the cost of getting less screen space for other widgets.
The real downside of that kind of widget, however, is that it's really hard to specify reasonable initial behaviour. Maybe we could overcome that with weights, so the application could specify to use, say, 30% for one subwindow and 70% for the other. But it would probably mean that there would be no automatic layout calculation to make other widgets fit in their natural size.
Why not just allocate the initial size as if it was a VBox? This would have the advantage that it could be translated directly to a VBox for interfaces that don't support it, like ncurses. If the user wants to change its size, let him. Cheers, Ricardo
It would work well for wigets that don't have a natural size to begin with, such as selection boxes, tables, rich text. Others like buttons, combo boxes etc. would very often look very odd -- too large or too small, depending on all the other widgets and the specified weights.
Other than that, this shouldn't be so hard to do for the Qt UI, and probably similar for the Gtk UI. But would it also work for NCurses? I have no clue.
In general, we probably want to have such a widget (but not for 10.3 - too late). But also in general, needing it is usually an indicator for overcrowded dialogs. It might be worth while to try to figure out another way of presenting the information.
CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

If this does vertical splitters too it could be used to resolve this bug I filed a couple of years ago: https://bugzilla.novell.com/show_bug.cgi?id=113699 _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Tuesday 19 June 2007 21:44, Benji Weber wrote:
If this does vertical splitters too it could be used to resolve this bug I filed a couple of years ago: https://bugzilla.novell.com/show_bug.cgi?id=113699
The widget in question there is a YQWizard which is written in C++/pure Qt anyway, so using a QSplitter there had been an option all the time. See comment #2. And then the discussion went pretty much overboard IMHO... CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Stefan Hundhammer wrote:
On Tuesday 19 June 2007 21:44, Benji Weber wrote:
If this does vertical splitters too it could be used to resolve this bug I filed a couple of years ago: https://bugzilla.novell.com/show_bug.cgi?id=113699
The widget in question there is a YQWizard which is written in C++/pure Qt anyway, so using a QSplitter there had been an option all the time. See comment #2. And then the discussion went pretty much overboard IMHO...
Geat! ;) Let's do it that way, at least for YQWizard as a 'test' :) L.

Ter, 2007-06-19 às 20:44 +0100, Benji Weber escreveu:
If this does vertical splitters too it could be used to resolve this bug I filed a couple of years ago: https://bugzilla.novell.com/show_bug.cgi?id=113699
yast-gtk suffers from the same, heh. :P I wonder if a solution could be to just layout the tree view horizontally on top of the content. This would get rid of the double scrolling, and vertical scrolling is much more pleasant than horizontal anyway, now with the advent of the wheel mouse. But this would be an unusual presentation... I guess we'll just put a splitter there then as you suggest. Cheers, Ricardo
_ Benjamin Weber
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Ter, 2007-06-19 às 15:49 +0200, Lukas Ocilka escreveu:
Hi,
When YaST developer or designer are designing the YaST dialogs, they need to define some relative sizes between widgets. Unfortunately, the worst cases cannot be expected and we usually ignore them.
This splitter idea would be useful, and the example you gave is a good one. However, I don't see how that relates to relative sizing, and I object to that. YCP writers abuse the weight property too much, and it results in dialogs where you need to stretch the window to see some widget; and past a certain point, it ruins aesthetics. In a way, you are outsourcing that work to the user. Users.ycp features such an abuse: http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/users-small.png http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/users-big.png The containers that GTK+ ships with don't feature weights and you can actually layout things better. Lists and other widgets, when used like in the shots, should be set as not stretchable, and shown at their full size (if they are not too big; otherwise, truncate their requested size and let them expand till its maximum size). Where the weight may make sense is, for instance, if you had a few tables at the center, with different number of columns... What do you think? Cheers, Ricardo
Please, see the attachment in this mail. The 'Repository Description' is always replaced with a new one when some other repository is selected in the 'List of Repositories'. The worst case is that there fifty repositories in the 'List of Repositories' but most of the descriptions need thirty lines in the 'Repository Description'. Please, don't write that it would be a _wrong description_, such cases just happen time to time.
My idea of a solution would be a user-controllable slider in UI - a new widget for graphical UI. Users could then themselves decide what is more important for them if the data don't fit the UI because screen is not inflatable ;)
I'd like to ask YaST developers whether they feel this is worth a feature request and whether it makes even sense to want it. I know that both Qt and GTK+ could implement it but I don't have any idea how difficult would it be.
Please, before writing "wrong UI design", "wrong data" ... think about that a few seconds :) If you always wanted such UI feature, write it too ;) Rather think about the advantages of it first :)
Thanks & Bye Lukas
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Ricardo Cruz wrote:
Ter, 2007-06-19 às 15:49 +0200, Lukas Ocilka escreveu:
Hi,
When YaST developer or designer are designing the YaST dialogs, they need to define some relative sizes between widgets. Unfortunately, the worst cases cannot be expected and we usually ignore them.
This splitter idea would be useful, and the example you gave is a good one. However, I don't see how that relates to relative sizing, and I object to that. YCP writers abuse the weight property too much, and it results in dialogs where you need to stretch the window to see some widget; and past a certain point, it ruins aesthetics. In a way, you are outsourcing that work to the user.
Relative size is used for the initial sizes presented on the screen. When designing a dialog, you'll probably want to define how it should initially look like. Then, splitter could be used to change that layout if needed. The default layout should be designed to be enough good for most of cases.
Users.ycp features such an abuse: http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/users-small.png
Here, you could use the relative size: Groups: 1/3 width of the screen, the other widgets in another HBox occupying 2/3 of the screen. I'm afraid that this dialog was not designed nor tested for so small screen, that's all.
http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/users-big.png
The containers that GTK+ ships with don't feature weights and you can actually layout things better. Lists and other widgets, when used like in the shots, should be set as not stretchable, and shown at their full size (if they are not too big; otherwise, truncate their requested size and let them expand till its maximum size).
Where the weight may make sense is, for instance, if you had a few tables at the center, with different number of columns...
What do you think?
Text-entries are stretchable by default. All those widgets are stretchable probably to be aligned with each other. If it is a bug and doesn't work well even in Qt or Ncurses, it's worth a bugreport. L.

Qui, 2007-06-21 às 10:21 +0200, Lukas Ocilka escreveu:
Ricardo Cruz wrote:
Ter, 2007-06-19 às 15:49 +0200, Lukas Ocilka escreveu:
Hi,
When YaST developer or designer are designing the YaST dialogs, they need to define some relative sizes between widgets. Unfortunately, the worst cases cannot be expected and we usually ignore them.
This splitter idea would be useful, and the example you gave is a good one. However, I don't see how that relates to relative sizing, and I object to that. YCP writers abuse the weight property too much, and it results in dialogs where you need to stretch the window to see some widget; and past a certain point, it ruins aesthetics. In a way, you are outsourcing that work to the user.
Relative size is used for the initial sizes presented on the screen.
When designing a dialog, you'll probably want to define how it should initially look like.
Relative sizing is no better than relative positioning; where you set a window size, and everything on absolute coordinates and then the layout engine will apply the proper transformation as the user resizes the window (used to give dynamic layout for old generation absolute layout engines). In modern layouts, you set the central widget(s) as stretchable, and the auxiliaries as not. Otherwise you ruin user expectation and aesthetics. In the users.ycp case they are even being used to pass the work of proper layouting to the user, forcing him to enlarge the window if he uses a font size bigger than yours. A fix for this could be to allow YCP writters to set the size policy of the MultiSelectionBox, so that it doesn't shrink or enlarge horizontally.
Then, splitter could be used to change that layout if needed. The default layout should be designed to be enough good for most of cases.
Users.ycp features such an abuse: http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/users-small.png
Here, you could use the relative size: Groups: 1/3 width of the screen, the other widgets in another HBox occupying 2/3 of the screen.
I'm afraid that this dialog was not designed nor tested for so small screen, that's all.
That's the default yast-gtk size. heh. Our default size is smaller than yast-qt (we enlarge the window if necessary). In any case, I have made a work-around for this; scrollable widgets minimum size should be its child size or 120 pixels, whatever is lower. Cheers, Ricardo
http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/users-big.png
The containers that GTK+ ships with don't feature weights and you can actually layout things better. Lists and other widgets, when used like in the shots, should be set as not stretchable, and shown at their full size (if they are not too big; otherwise, truncate their requested size and let them expand till its maximum size).
Where the weight may make sense is, for instance, if you had a few tables at the center, with different number of columns...
What do you think?
Text-entries are stretchable by default. All those widgets are stretchable probably to be aligned with each other. If it is a bug and doesn't work well even in Qt or Ncurses, it's worth a bugreport.
L.
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (18)
-
Bart Whiteley
-
Benji Weber
-
Bernhard Walle
-
Dominic Reynolds
-
Druid
-
Duncan Mac-Vicar Prett
-
Francis Giannaros
-
Jiří Suchomel
-
Johannes Meixner
-
Katarina Machalkova
-
Klaus Kaempf
-
Lukas Ocilka
-
Martin Schlander
-
Martin Vidner
-
Pascal Bleser
-
Rebecca Walter
-
Ricardo Cruz
-
Stefan Hundhammer