Netbook Friendly

[dmoore]

I picked up a eee pc yesterday. nice piece of kit for the money. First thing  I did was put an eee derivative of ubuntu (eeebuntu) and installed C::B from source. C++ compiling obviously isn't a netbook strong suit, but it gets the job done eventually.

most things worked without a hitch, except netbooks suffer from a reduced screen resolution on a small screen (1024*600, 10inch). Quite a few of the dialogs are too big for the screen and toolbars create a lot of clutter. It's easy enough to work around the too big dialog's with compiz moveable windows shortcuts, but it would be nicer if things fit on screen

Here's a list of issues
* Environment Settings dialog: ThreadSearch settings form makes the overall dialog too tall
* Editor Settings dialog too tall: General settings (could probably redistribute some of these items to other panes), CodeCompletion, wxSmith, and maybe IncrementalSearch
* Build Option Dialog, Compiler and Debugger Settings: too tall, not sure of cause
* CodeCompletion toolbar very wide and not sizeable.

[thomas]

I have the opposite problem.

Working on a 24'' display, it annoys me greatly that the dialogs are too small. Whenever I access compiler options, I have to scroll down the list (and you can't even use the mouse wheel for that!) for the sole reason that the dialog uses only a third of the available screen height (of which less than half is used for the option list).

Maybe we should invent something like a "large mode" and "small mode" of operation, which adjusts the default sizes to reasonable sizes (for example assuming a screen height of 600 for "small", 768 for "normal", and 1200 (or 1050) for "large").

[dmoore]

yes, I agree. no point not using the screen real estate if it's there.

[dmoore]

the challenge is coming up with a system that doesn't burden C::B and plugin devs

[Ceniza]

The only idea I come up with is to organize everything in virtual tabs. You classify a bunch of widgets enough for a small screen into a virtual tab. You use as many of those as you need to fit everything you want to show. For a small screen, each virtual tab maps to a real tab. If the screen is slightly bigger, you can show two of those virtual tabs per real tab. The bigger the screen, the more virtual tabs you can map to real ones. With a big screen you would expect to have no tabs at all, only a big window with everything in it.

My 2 euro cents.

[dmoore]

interesting Ceniza... one approach to that would be much like a modern web page: every tab could be stacked one under the other with a scrollbar at right. the left panel would contain the icons as a shortcut to scroll to the relevant section. (still need some way to deal with wider displays - I guess the tabs could be stacked as a grid?)

[Ceniza]

interesting Ceniza... one approach to that would be much like a modern web page: every tab could be stacked one under the other with a scrollbar at right. the left panel would contain the icons as a shortcut to scroll to the relevant section. (still need some way to deal with wider displays - I guess the tabs could be stacked as a grid?)

A grid would be the way to show more than one virtual tab. Additionally, what would be the text of the virtual tab would become a quite visible label. The first implementation could just use one of those boxsizers with labels (even though they are not that "cute"). The problem with the stacked tabs and the scrollbar is that they would only be useful in height. A grid would still be needed to make use of the width.

I'll let you know if I come up with more ideas.

[Jenna]

Today I stumbled over the wxScrollingDialog class: http://www.anthemion.co.uk/code.htm#scrollingdialog.

It can be an alternative to fit dialogs on small screens.

I just tested it with the wxAui-branch and it works more or less out of the box.

Implementing it was quite easy (not tested with contrib-plugins or on windows).

I attach a screenshot from a 800x600 editor dialog.

It's surely not the best looking way to handle small screens, but it's much better than having parts of a dialog, that are not reachable.

[attachment deleted by admin]

[MortenMacFly]

I just tested it with the wxAui-branch and it works more or less out of the box.

Nice work Jens! Looks very good to me. How mature is wxScrollingDialog? Is it a (Julian Smart) 3rd Party addon or even already within a wx branch?

[dmoore]

certainly a decent workaround. my only fear is that Thomas will now demand 2400x1600 dialogs.

more seriously, I'd still like to see a prototype of ceniza's proposal as well.

[Biplab]

I just tested it with the wxAui-branch and it works more or less out of the box.

Nice work Jens! Looks very good to me. How mature is wxScrollingDialog? Is it a (Julian Smart) 3rd Party addon or even already within a wx branch?

I believe it's already inside wx branch in the form of wxScrolledWindow. Follow this url for more details.

http://docs.wxwidgets.org/stable/wx_wxscrolledwindow.html

[Jenna]

I just tested it with the wxAui-branch and it works more or less out of the box.

Nice work Jens! Looks very good to me. How mature is wxScrollingDialog? Is it a (Julian Smart) 3rd Party addon or even already within a wx branch?

I believe it's already inside wx branch in the form of wxScrolledWindow. Follow this url for more details.

http://docs.wxwidgets.org/stable/wx_wxscrolledwindow.html

No,

But wxScrollingDialog uses wxScrolledWindow.

wxScrollingDialog is a convenience class that makes it easy to use standard dialogs with wxScrolledWindow, without having to change them all manually or to care about the screens size.

I include the readme.txt comimg with wxScrollingDialog, that describes how it works:

wxScrollingDialog
=======================================

This class turns your existing wxWidgets dialogs into scrolling dialogs,
when there isn't enough space to show all of the dialog at once. The standard
buttons remain on the screen at all times. This is especially useful for
devices such as the Eee PC which have a small screen.

To use, just derive from wxScrollingDialog. If you have dialog buttons that do
not have the standard identifiers (such as wxID_OK, wxID_CANCEL and wxID_APPLY)
then call AddButtonId multiple times with the identifiers of the buttons to be
left unscrolled.

The class works by searching first for a wxStdDialogButtonSizer, then a horizontal
wxBoxSizer containing standard buttons, and then individual standard buttons.
These sizers and/or buttons are removed from the existing sizer hierarchy and
added to the bottom of the dialog, while the rest of the hierarchy is attached
to a new wxScrolledWindow. The dialog is then laid out again, and if the dialog
is too big for the display, the scrollbars are enabled and the dialog resized to
fit the display.

In most situations, the layout will be similar to the original dialog. However,
if you wish to disable the layout changes, you can call SetAdaptationLevel with
0 before calling Show or ShowModal. You might want to do this, for example,
if you know in advance that the display is large enough.

For further discussion about adaptation to the Eee PC screen, see
http://wxwidgets.blogspot.com/2007/12/programming-for-eee-pc-with-wxwidgets.html

Julian Smart, December 2008

[Ceniza]

certainly a decent workaround. my only fear is that Thomas will now demand 2400x1600 dialogs.

more seriously, I'd still like to see a prototype of ceniza's proposal as well.

I also have a 24" screen, and it is true small dialogs do not make much sense. A 2400x1600 dialog would be nice if we could fit it in the so limited 1920x1200 resolution of a 24" screen

For the prototype, at least a decision about screen distribution would be necessary. The algorithm should be given the screen resolution, size of virtual tab (should be the same for all of them, or just calculate the longest width and height) and number of virtual tabs. It should try to distribute them with an aspect ratio close to the screen's, and leaving as few empty spaces as possible. A constraint would be, of course, to group into tabs when no more columns/rows can be added.

Another issue to discuss can be best described by quoting a Pink Floyd's song:

"What shall we use to fill the empty spaces?"

[dmoore]

jens: patch file?

[Jenna]

jens: patch file?

I patched an old wxAui-branch.
That means I have to patch the actual trunk to create a patch.
Hopefully this evening/night (it's 10pm here) or tomorrow.