[yast-devel] yast-ui: Lack of const for code arrays
Hi, On yast-ui headers, we have code as follows: virtual char *widgetClass() { return "YCheckBox"; } This results in a ton of warnings on newer versions of g++ (at least 4.2.1). This function names the class, while debugLabel() names the object, so the string should always be constructed like that. Let's just make the pointer const. Patch appended. Thanks, Ricardo
Qua, 2007-10-10 às 15:19 +0100, Ricardo Cruz escreveu:
Hi,
On yast-ui headers, we have code as follows: virtual char *widgetClass() { return "YCheckBox"; }
This results in a ton of warnings on newer versions of g++ (at least 4.2.1). This function names the class, while debugLabel() names the object, so the string should always be constructed like that. Let's just make the pointer const. Patch appended.
Thanks, Ricardo
Ah, let's flag the function as const while we are at it. Ricardo
On Wednesday 10 October 2007 16:19, Ricardo Cruz wrote:
On yast-ui headers, we have code as follows: virtual char *widgetClass() { return "YCheckBox"; }
This results in a ton of warnings on newer versions of g++ (at least 4.2.1). This function names the class, while debugLabel() names the object, so the string should always be constructed like that. Let's just make the pointer const. Patch appended.
It's already done in the mod-ui branch. This will become the new trunk in a while. Until then, let's please keep any change to the trunk minimal so merging everything will be reasonably possible. The new mod-ui branch: http://svn.opensuse.org/svn/yast/branches/tmp/sh/mod-ui/ The general idea: http://idea.opensuse.org/content/ideas/making-the-yast2-ui-usable-without-al... Readme / Changelog: http://svn.opensuse.org/svn/yast/branches/tmp/sh/mod-ui/core/libyui/src/Chan... Architecture diagrams (visible from the outside, might take an hour or two to get mirrored there): http://www.suse.de/~sh/y2-ui-arch-old.pdf http://www.suse.de/~sh/y2-ui-arch-modular.pdf I talked with mmeeks about it some time ago. I hope he kept you updated. 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
Hi Stefan, Michael will go next to your meeting in Prague. I talk to him then... Having a look at your repo, I see stretchable() wasn't yet made safe to call for childless containers. :( I'm asking that for awhile now. And what about getting rid of SelectionBox and friends, for a flexible Table? As far as I can see, that's the main blocker for a YCP implemented package selector. The hardware tools could use some nicer listings too. Cheers, Ricardo Qui, 2007-10-11 às 13:49 +0200, Stefan Hundhammer escreveu:
On Wednesday 10 October 2007 16:19, Ricardo Cruz wrote:
On yast-ui headers, we have code as follows: virtual char *widgetClass() { return "YCheckBox"; }
This results in a ton of warnings on newer versions of g++ (at least 4.2.1). This function names the class, while debugLabel() names the object, so the string should always be constructed like that. Let's just make the pointer const. Patch appended.
It's already done in the mod-ui branch. This will become the new trunk in a while. Until then, let's please keep any change to the trunk minimal so merging everything will be reasonably possible.
The new mod-ui branch:
http://svn.opensuse.org/svn/yast/branches/tmp/sh/mod-ui/
The general idea:
http://idea.opensuse.org/content/ideas/making-the-yast2-ui-usable-without-al...
Readme / Changelog:
http://svn.opensuse.org/svn/yast/branches/tmp/sh/mod-ui/core/libyui/src/Chan...
Architecture diagrams (visible from the outside, might take an hour or two to get mirrored there):
http://www.suse.de/~sh/y2-ui-arch-old.pdf http://www.suse.de/~sh/y2-ui-arch-modular.pdf
I talked with mmeeks about it some time ago. I hope he kept you updated.
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
On Thursday 11 October 2007 18:39, Ricardo Cruz wrote:
Hi Stefan, Having a look at your repo, I see stretchable() wasn't yet made safe to call for childless containers. :(
Hm - well, OK, that shouldn't be so hard. OTOH a childless container doesn't serve any purpose.
I'm asking that for awhile now. And what about getting rid of SelectionBox and friends, for a flexible Table?
AFAICS Table can already do everything SelectionBox can do -- and then some. But we can't drop support for a widget just like that. We have tons and tons of code that would break. One of the great challenges of this UI refactoring is to not break all of YaST2. I hope to do the migration without any change to any existing YCP code. This migration is supposed to be painless for the maintainers of the YCP modules. And in those very rare cases where some old quirks just don't work any more I'll help the maintainer out with a fix (that should be no more than 2-3 lines of change).
As far as I can see, that's the main blocker for a YCP implemented package selector.
NOBODY wants a YCP based package selector. We had that thing in the bad old days (SuSE 6.x, 7.x, 8.1), and it was a nightmare. There is a limit to the gimmicks one can do with a language like YCP and a abstracted, yet stripped-down UI model we use.
The hardware tools could use some nicer listings too.
That's true. I had suggested quite some time ago that we could add a dedicated higher-level widget for that kind of thing. Please note that IMHO the way to go is the opposite of what you proposed with the package selector: Don't do overly complex things in YCP with the limited feature set an abstraced UI like ours is bound to have. Rather, do the nifty stuff in a purpose-written C++ widget that can be optimized for the respective capabilities of the target UI. There are many things you just can't do with a text based UI, but why limit the users of a graphical UI to that, too? Only so far nobody had a good idea how such a dedicated widget could look like. 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
On Friday 12 October 2007 11:46, Stefan Hundhammer wrote:
Having a look at your repo, I see stretchable() wasn't yet made safe to call for childless containers. :(
Hm - well, OK, that shouldn't be so hard. OTOH a childless container doesn't serve any purpose.
BTW it was a theoretical problem anyway since the only way to create the respective widgets was with YCP calls, and the UI's YCP dialog term parser would not allow to create a container widget without a child. Now that it can reasonably be called from C++ it's different of course. The two remaining places where a hasChildren() call was missing are now fixed. Thanks for pointing that out. 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
Sex, 2007-10-12 às 11:46 +0200, Stefan Hundhammer escreveu:
On Thursday 11 October 2007 18:39, Ricardo Cruz wrote:
Hi Stefan, Having a look at your repo, I see stretchable() wasn't yet made safe to call for childless containers. :(
Hm - well, OK, that shouldn't be so hard. OTOH a childless container doesn't serve any purpose.
We do the layouting ourselves. Whenever a widget is added to a container, its parent checks whether the container's stretchability property has changed (and in case it has, so does parent's parent, and so on). yast-core creates a container and adds it to the parent, while it is childless. I guess we could hack YDialog::setSize() to order a full check. That wouldn't be as simple or efficient, and we can use the flexibility now with the changes.
As far as I can see, that's the main blocker for a YCP implemented package selector.
NOBODY wants a YCP based package selector. We had that thing in the bad old days (SuSE 6.x, 7.x, 8.1), and it was a nightmare. There is a limit to the gimmicks one can do with a language like YCP and a abstracted, yet stripped-down UI model we use.
I don't know the shortcomings of YCP (it isn't very comfortable to program in, for sure; and the events are a bit crude, you wouldn't know what row the user toggled), the UI API could be improved though. With a more generic Table, we would construct the columns based on types, and whether they are user editable. We would need to decide whether we want the frontend to re-act to it, or just report it and let YCP take care of it. But I think we can pull it off a pretty simple API that lets the YCP coder do toggled pixmap columns, tables with multiple toggles, ...
The hardware tools could use some nicer listings too.
That's true. I had suggested quite some time ago that we could add a dedicated higher-level widget for that kind of thing. Please note that IMHO the way to go is the opposite of what you proposed with the package selector: Don't do overly complex things in YCP with the limited feature set an abstraced UI like ours is bound to have. Rather, do the nifty stuff in a purpose-written C++ widget that can be optimized for the respective capabilities of the target UI. There are many things you just can't do with a text based UI, but why limit the users of a graphical UI to that, too?
Only so far nobody had a good idea how such a dedicated widget could look like.
I just mean to have the lists a little more pretty, and making the all information visible. Like this: http://en.opensuse.org/Yast_UI_Future#Hardware_Listing Would be just a simple change. We'd need support for a pixmap column (ignored by ncurses) -- I think, at least SelectionBox, has already that, right? And then we add support markup at the specification. ncurses could just ignore it, and should be just a matter of enabling it on qt and gtk. Cheers, Ricardo
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
participants (2)
-
Ricardo Cruz -
Stefan Hundhammer