Netbook Friendly

[dmoore]

the aui branch is probably fine (unless really old). I have a recent copy of the aui branch on my machine. no hurry though

[Jenna]

I attach a 7z-file containing the patch against svn r5469 and the files scrollingdialog.cpp and scrollingdialog.h and scrollingdialog.patch.

Copy scrollingdialog.cpp to src/sdk/ and scrollingdialog.h to src/include.

Don't apply scrollingdialog.patch, it's the patch against the original scrollingdialog.*-files I used to make it useable with C::B.
Its include just for documentation purposes.

Apply scrollingdialog_20090223-1.patch.
It does not work with actual wxAui-branch, there will be some failed hunks if you try.

The patch is not (yet) tested under windows.
So it still might crash with some dialogs, I tested most of them, but most likely forgot some.

Contrib-plugins are also tested.
wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files.
That means of course that, if wxs-files are opened with wxSmith the appropriate source- and header-files will be changed, so that the standard wxDialog will be used again.

To test how it works, I reduced my actual screen-size to 768x576 (really small, normally I have 1920x1200 on my laptop).

EDIT:

On Windows don't forget to add the two new files to the project-file (both in target sdk).

[attachment deleted by admin]

[dmoore]

patch applies fine but i get cc1plus segfault building ipc.cpp (encoding issue or maybe i corrupted my working copy?)

[Jenna]

Do you use gcc 4.3 ?

I have the same problem (at least on 64-bit) withh gcc 4.3 when building C::B from inside C::B, never found the reason.

You can remove ipc.cpp from the project-file, it's not used.

[MortenMacFly]

the aui branch is probably fine (unless really old).

Huh? In fact it's quite up-to-date! (At last after the last merge...)

[MortenMacFly]

I attach a 7z-file containing the patch against svn r5469

Very nice work, Jens.

wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]

...although this is a serious show-stopper to me. We should really think about whether the benefits are worth that costs. For me this drawback makes it quite useless (unfortunately). I would vote for leaving it as a proof-of-concept in the patch tracker.

...or do you (all devs) seriously thinking to apply this into trunk?

[Jenna]

wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]

...although this is a serious show-stopper to me. We should really think about whether the benefits are worth that costs. For me this drawback makes it quite useless (unfortunately). I would vote for leaving it as a proof-of-concept in the patch tracker.

...or do you (all devs) seriously thinking to apply this into trunk?

The xrc-files are no problem.
They get loaded as normally, and can be used as before, even if the loaded dialog is inherited from wxScrollingDialog (otherwise the most of our dialogs would fail).
I left them untouched, because the xml-loader don't know wxScrollingDialog and can not load the resources correctly.

The only real problem is with wxSmith, because it directly changes the source and headerfiles, and every change (to use wxScrollingialog) will be changed back to wxDialog.

EDIT:
it should also be possible (and that would be the cleaner way, I think) to overwork all dialogs, to use wxScrolledWindow to make the client-part scrollable.
The "main"-buttons can be left in the unscrolled-part as it is done by wxScrollingDialog.
I don't know whether wxSmith knows wxScrolledWindow, but if not it can surely be implemented.

[PsYhLo]

I attach a 7z-file containing the patch against svn r5469

Very nice work, Jens.

wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]

...although this is a serious show-stopper to me. We should really think about whether the benefits are worth that costs. For me this drawback makes it quite useless (unfortunately). I would vote for leaving it as a proof-of-concept in the patch tracker.

...or do you (all devs) seriously thinking to apply this into trunk?

one suggestion it can be used like feather
place it somewhere with one check box to set it on and off for those who want it

[killerbot]

I would be a very nice feature.
But I am biased, because next month when I am in the USA I will most probably buy a .... netbook. And one of the first things will be building and using CB ;-)

[Jenna]

place it somewhere with one check box to set it on and off for those who want it

It would be possible to use a switch to allow wxScrollingDialog to rearrange the dialogs.

But I don't think it is needed, because for screens that are large enough, it should not make a visible difference.

[dmoore]

the aui branch is probably fine (unless really old).

Huh? In fact it's quite up-to-date! (At last after the last merge...)

i was referring to jens post where he said

I patched an old wxAui-branch.

Do you use gcc 4.3 ?

I have the same problem (at least on 64-bit) withh gcc 4.3 when building C::B from inside C::B, never found the reason.

You can remove ipc.cpp from the project-file, it's not used.

I'm using 4.3. I haven't had the problem until last night. As you suggested, I removed the file and it compiled. However, I would like to understand what broke the compiler...

Your scrolling dialog tweaks get the job done nicely. thanks!

I started hacking at a class derived from wxListbook to stack dialogs in a scrolled pane as an alternative. might take me a day or two to get working. (more from lack of time than any great complexity)

[nanyu]

I think it was better for using "wxNotebook" control than "wxScrollDialog"..

[dmoore]

I think it was better for using "wxNotebook" control than "wxScrollDialog"..

if you bothered to test the patch, you'll see that it still uses a notebook. the notebook itself is put inside a scrolling window, which will automatically add scrollbars if the panel is too big to fit on screen.

[thomas]

Can't we show the options panel as a cbEditor or instead of the editors? Pretty much like the "start here" page works, too.

That way, we could make use of the entire screen estate, and scrollbars would fit in neatly. This would work better both for small and large screens.

[dmoore]

Can't we show the options panel as a cbEditor or instead of the editors? Pretty much like the "start here" page works, too.

That way, we could make use of the entire screen estate, and scrollbars would fit in neatly. This would work better both for small and large screens.

I agree this would be nice and more along the lines of what Ceniza and I have been thinking.