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.

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 [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

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 Wednesday 20 June 2007 10:24, Benji Weber wrote:

On 20/06/07, Rebecca Walter 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

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

On 6/20/07, Rebecca Walter 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

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:

...

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

Hello, On Jun 21 16:29 Bart Whiteley wrote:

Pascal Bleser wrote:

...

Klaus Kaempf wrote:

...

* Lukas Ocilka [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

On 22/06/07, Rebecca Walter 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

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

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

Den Friday 22 June 2007 19:49:28 skrev Benji Weber:

On 22/06/07, 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.

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

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

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

On Wednesday 20 June 2007 09:33, Bernhard Walle wrote:

* Rebecca Walter [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

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.

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

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

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

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.

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

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

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 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

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 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 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

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.