Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Netbook Friendly

<< < (5/7) > >>

MortenMacFly:

--- Quote from: jens on February 23, 2009, 01:00:27 am ---I attach a 7z-file containing the patch against svn r5469

--- End quote ---
Very nice work, Jens.


--- Quote from: jens on February 23, 2009, 01:00:27 am ---wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]

--- End quote ---
...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:

--- Quote from: MortenMacFly on February 23, 2009, 07:16:35 am ---
--- Quote from: jens on February 23, 2009, 01:00:27 am ---wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]

--- End quote ---
...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?

--- End quote ---

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:

--- Quote from: MortenMacFly on February 23, 2009, 07:16:35 am ---
--- Quote from: jens on February 23, 2009, 01:00:27 am ---I attach a 7z-file containing the patch against svn r5469

--- End quote ---
Very nice work, Jens.


--- Quote from: jens on February 23, 2009, 01:00:27 am ---wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]

--- End quote ---
...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?

--- End quote ---

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:

--- Quote from: PsYhLo on February 23, 2009, 07:48:18 am ---place it somewhere with one check box to set it on and off for those who want it :)

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version