A nice addition would be the ability to have a "percentage" property for the vertical and horizontal scrollbars to roughly set the position of the slider on the bar.

The goal being to allow one to create wireframes of partly edited views, where the scrollbar has been used to scroll down until a given point.

In my current use case, I want to scroll down to something, which means I would have partly covered items and a slider still at the top-most position. This looks immediately confusing to the eye.

My current workaround is a white panel to hide the current slider, and an empty panel to create one on top of the slider, and then group the whole thing.

maybe allowing them to be "greyed" to show disable scrollbars (or scroll bars without sliders) would also be interesting), but definitely less useful. That becomes quite fine-grained at this point.


I have this item on my list by I was waiting for a request like yours before adding it. I just wanted to know if you are looking to have this property just for Vertical/Horizontal Scrollbar widgets, or do you need it also in widgets that support Vertical scrollbar property (like Panel, Table, Tree, etc).

Hmm, I wasn't aware that there was such a property in the panels/trees/etc :)

In any case, yes, I'd like it for all of them, but I'm not picky, I can live with what I have at the moment, and you can roll them out at the pace you want, it's fine if only scrollbars get updated first.

And thanks :)

Just checked, and Panels do have an optional scrollbar control... dammit :)

Yes, it would be good if it could be editable (disabled/enabled status + percentage) for these as well, that would probably simplify my drawings a bit.

Well I guess the underlying rendering is probably the same for you, as it's probably a composition of both widgets, but that would make my screens' outlines more streamlined.

Scrollbar also works for Text Area widget. Perhaps it's closed to what you are looking for.

Text Area also supports the disabled state. Unfortunately I've just checked and it doesn't render the scrollbar as disabled. I think I should fix it. Would it be of any help to you?

No, don't worry, the only thing I could use would be the percentage thing, instead of patching things with panels as explained above.

And it's not that important anyway.

The disabled state would be just for looks, it's not really important either.

Thanks for the quick feedback though.


I've made the required changes and you can now adjust the value for sliders, progress bar and scrollbars. I've also changed a bit the look of scrollbar widgets. I'd like to hear what you think. You can test these changes using the development version available here:


Hello Petru,

Thanks a lot. I'll give it a shot today. Can I update my current installation using the staging area's update site, or do I need a clean install?


Yes, you can update you current installation. Just proceed the same way as you would when installing the plugin from scratch but using the staging update site.

It looks great!

Very easy to use and not intrusive, I think it's fine.

The new design for the scrollbar widget surprised me a bit, but I was used to it after 2 minutes. Maybe the fact that the slider is "plain dark" now instead of being just a bordered rectangle makes it a bit too visible and draws the reader's focus, but I really don't know.

I think it's OK.

By the way when I updated this I noticed that my tables had an alpha which was not 100%, was this part of the changes you made, or did I do this by mistake?


I thought that since the position of the scrollbar is now adjustable the thumb should be more visible. Maybe I should experiment more with the color and find something in between black and white. I'll try filling the rectangle with the gray and see what it gives.

By the way when I updated this I noticed that my tables had an alpha which was not 100%, was this part of the changes you made, or did I do this by mistake?

What value was it if not 100%? I've made some changes to the slider widget that is used to adjust Alpha and Scrollbar values. Do you see any change in color or is it just that the slider doesn't look right?

The slider looked alright, it was just a bit lighter than the rest. Two of my screens had an alpha of 80% I think, instead of 100%.

But I just tried with a brand new one (just adding a new table to my screen) and this one was normal, so I guess I must have changed it one my first without noticing, and then I created the second screen as a copy of the first one.

So it most probably has nothing do to with your updates. I just didn't notice before.


Thanks for looking into this. Meantime I've changed the color of the thumb to something lighter. I'd like to hear if you like it better. Since you are using a development version you just need to use "Check for updates" to get the latest version.

Thanks, it does look better that way, in my opinion.

I think I found a small defect/"bug" with this. If you put a scrollbar on a "Window" container, and reduce this container to a small height (I do this because I mock something using ExtJS, where you can have collapsible panels/windows where only the title bar is kept visible), then the scrollbar gets visible on top of the window's title bar.

Basically, any height for the window which is smaller than the "grey" area of the scrollbar (the slider) will have said slider appear on top of the window.

I can send you a screen shot if you want.

Not a big bug and not very relevant, as I am clearly using windows in a way they weren't exactly meant to be, but I thought you might want to know.

(And the woraround is pretty easy, as you only need to disable the scrollbar).


Perhaps there is a need for a new type of widget? Could you give me some more pointers about how it looks/works?

Sure, you can visit http://www.extjs.com and their demos.

More particularly, this one demonstrates a window with a folding icon.

But I am not sure you need a new widget for this. It sure would be easier to use, but then you'd slowly need to cater for the needs of everybody with every single variation in all the existing widgets and look-and-feels. Which means you'd ever end up with a very wide range of controls/widgets, or very extensible widgets. In the first case, it would be hard to find the ones you need, and in the second, it would get longer and trickier to configure them, thus removing the benefit of the wireframe system's simplicity and rapidity.

Maybe a potential approach would be to package several kinds of widgets in different categories, which you can install on demand from the update-site. Maybe a bit like Microsoft Visio has different kinds of charts. You could have an ExtJS widget bundle, a MacOS X widget bundle, etc...

But like I said: the idea of the wireframe is that it remains simple to just get through the main intent to your project's stakeholders (or at least, that's what I use it for). If it gets too fine-grained, then I'd take more time to build the wireframes, and project stakeholders would be more enclined to request wireframes that look closer to "perfection".

It's up to you, really. I can understand and appreciate the need for new features, but I think that then the hardest thing is to maintain the software scalability, in terms of install size, easy of maintenance, etc... Thankfully the Eclipse platform gives you most tools for that with the update manager and the configuration views.