planned widgets work (scollbars n such)

[ttlanhil]

currently the scrollbars are an add-on, and you have to check back to them to figure out what to draw in the window and all, which is more code than needed and a hassle to set up, it's also disintuitive to code, and doesn't act like people expect when they use a scrollbar, and having a set length just doesn't look right.

it'd be better if they were dynamically added/removed, and their position automatically selects what to draw.

for this to work, everything in a window has to be a widget, and all mouse-over, click, etc has to be handled by the widget itself. this also means you also need a spacer/custom widget with a size you can set for anything custom you want to do, with ability to be set to fixed location (like the requests button in buddy list). if you want to do any drawing to the window and such, you will use the custom widget for this

 

this means editing a lot of code though (mostly in widgets.c/h, I hope) and it'd be a pain to be working on this if there will be many commits to CVS while I work on it.

so, is anyone working on widgets.c/h? or planning to? (if it's just a small change or two you'd like to do sometime, then I can do that as well, just put a note here)

or is something like this not preferred, in which case I should work on other things (and I do have a few things on my todo list so this is possible ) ?

 

additional work planned:

when a window is shown( toggle or show_window() ), check that it's within screen bounds (mostly only needed when you resize down your resolution). if not, move it backward towards the screen till the players will be able to grab it (yes, this may be a little inconvenient if someone accidentally goes to 640x480 and back and their windows get cramped, but less of a pain than not being able to get your windows)

[ttlanhil]

actually, there's an alternative to making all windows widget-only, that's to have a new bounding-box widget (or frame, area, whatever) which will make and remove the scrollbas and such. I think similar to this is aleady done with the MULTIs in config window

the frame widget could be the whole window or just the part you want

[crusadingknight]

actually, there's an alternative to making all windows widget-only, that's to have a new bounding-box widget (or frame, area, whatever) which will make and remove the scrollbas and such. I think similar to this is aleady done with the MULTIs in config window

the frame widget could be the whole window or just the part you want

201804[/snapback]

Uhm.. yes, there is widget work going on. In fact, I have a patch which rewrites all the widgets to include default typing, which is ~1.2k lines. Please don't break it...

 

Anyway, the box widget (not exactly a bounding box) seems like an interesting idea, (take a look at tabs code from more window-in-window implementations.)

 

 

EDIT: Widget patch if you want to take a look at it, since you don't have access to where it's posted:

http://rootshell.be/~bremac/patches/widgetsfix.diff

Edited September 27, 2005 by crusadingknight

[ttlanhil]

okay, I'll do the frame-widget.

if I understand how it all works right, that'll work without too many changes when a window is changed to use the frame; we can still have a widget in a frame-widget in a tab-widget inside a window, so things should work nicely

 

as an upside, adding a widget type should be a pretty self-contained sorta patch, with all other windows that want to use it being able to be updated later

which is a good thing, because adding a new widget will probably overlap with what you're doing (heh, good thing I asked

Edited September 27, 2005 by ttlanhil

[crusadingknight]

as an upside, adding a widget type should be a pretty self-contained sorta patch, with all other windows that want to use it being able to be updated later

201936[/snapback]

Actually, they all have to be updated in the patch, otherwise, they break.

[ttlanhil]

Actually, they all have to be updated in the patch, otherwise, they break.

202032[/snapback]

your patch, yes, but I'm just adding a new widget type instead of changing existing ones. I'm mostly worried about how much work I have to do

[ttlanhil]

whoo! it's done, and works quite nicely! (if i do say so myself, which i like to be able to)

see Patch #629

 

the patch includes a demo of the frame, use ``#meep''... this obviously gets taken out before it goes into CVS, but it could be handy as to how it all works

the demo window isn't well done, so you can over-shrink your window or whatever. but the frame works nicely

 

because we don't have widgital nesting (that I could see) I had to work around that, which meant a second command after creation

to create something in a frame, you will:

move_to_frame(window_id, frame_id, label_add(window_id, NULL, "text", start_x, start_y));

you could also call the widget creation and then pass the ID to move_to_frame(), if you so desired

[Lachesis]

You cannot nest widgets, as they are something like atomic windows. You can nest windows. So if you need a container, just use a window. IIRC you can look at the implementation of the tabbed windows as an example.

[ttlanhil]

You cannot nest widgets, as they are something like atomic windows. You can nest windows. So if you need a container, just use a window. IIRC you can look at the implementation of the tabbed windows as an example.

202929[/snapback]

if I made a subwindow and added widgets to that, it'd be even more work, and then windows would have to have the scrollbars added automatically. that breaks the idea of a simple change

I did look at tabs, and I was going to use a nested window until i started thinking about how to dynamically add/remove/resize the scrollbars. headache time.

if someone wants to add dynamic scrollbars to windows, and then go and change all windows so they use only widgets (which we need, in order to be able to find the window virtual length, and you have to change them all otherwise you need two types of windows), and add another bare/custom/whatever widget type for wherever you want to draw it yourself... go ahead.

that's a huge amount of work, what I was originally thinking I'd have to do, and I decided there's gotta be a better way. widgets inside a frame works, and it's a minor adjustment

[Lachesis]

I see. Well, IMO all widgets should be windows too. Also instead of the expensive mechanisms used to show/hide subwindows, we should have a real root window, only draw that and make any window take care itself of drawing subwindows. You know, a little like the "real" window managers work But hm, I think there's no use in improving that as long as we're not allowed to use an OOPL. Though it is possible to do the same in C, it's tedious and error-prone. Not to mention -- in any case -- it's quite a bit of work, that didn't seem worth the effort in the past, yet it might do so if the complexity of the interface continues to grow at its current rate.

Edited September 30, 2005 by Lachesis

[ttlanhil]

"real" window managers work But hm, I think there's no use in improving that as long as we're not allowed to use an OOPL. Though it is possible to do the same in C, it's tedious and error-prone. Not to mention -- in any case -- it's quite a bit of work

203087[/snapback]

well, my frame has a title area, togglable border, dynamicly added/removed/resized scrollbar, and manages display of all its own widgets. so it's certainly possible to do (and didn't even take much code)

there will likely come a stage when we will need proper window management work to be automatic, because we'll just have so many windows n such