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